Re: lynx-dev short_url option

[Klaus Weide]

On Thu, 5 Aug 1999, Heather wrote:
> > On Thu, 5 Aug 1999, Heather wrote:
> > > Hmmm.  This makes me think, how can we reduce each of these best, maybe
> > > seperately.
> > > 
> > > A. Yeah, the protocol is nice to know, but frankly, most web URLs are 
> > > http,
> > >    and most of the rest are ftp.  (So, it is important if it's a mailto,
> > >    telnet, https, etc.) 
> > 
> > It may be http most of the time for most people.  All the more important
> > to make it visible when it differs from that "normal" case.
> 
> Weird, I could swear that you and I are -agreeing- here, unusual protocol
> types are important to preserve.

It can happen... :)

> > >    Problem is we're wasting 6 or 7 characters
> > >    on these common forms.  We could easily replace http:// with h: -
> > >    ftp:// with f: - and https:// with ssl:
> > 
> > Introducing yet another convention that one has to get used to, and that
> > on top of that looks like DOS drive letters, seems a very bad idea.
> 
> well, okay, maybe : is not the right seperator.
> 
> As for "another convention to get used to" ... is going to be that too.
> No excuse there.

But "..." is the "natural" way to denote that something has been omitted.
It is a common convention that I assume most users already know from
other contexts.

> > > B. Hostname isn't nearly so important if it's on the local site... even if
> > >    fully spec'd out.  At least to me.  
> > 
> > All the more important to show it when it differs from the "expected"
> > one.  (i.e. from the local host?  from that of the current page?)
> 
> From the current page is what I was thinking.  Although, it could get real
> tiring seeing file:/// in dired mode, too.

The "current page" in dired mode has a URL that starts with
"file://localhost", so if URL parts that are common between the current
page and the current link were omitted you would not see "file://".

> > >    port number - now *that*'s important.
> > 
> > Why would it be more important than the hostname or the protocol?
> 
> If you have a firewall, [...]

Ok.

Lynx already discards port specifications durring normal URL parsing
if the port is the same as the default port for the scheme, so it
seems this is already dealt with in the most convenient way.
  
> > > C. I think this could be split even further... for some folk, it's only
> > >    important up to the part where they learn it's a CGI script, all the 
> > > GET
> > >    data after that is sort of gibberish.
> > 
> > You are introducing confused terminology here: "GET data" and (below) "GET
> > portion".  Correct is to call it the "query part" of the URL.  The query
> > part doesn't have any more GET nature than e.g. the path.
> 
> OK, poor terminology on my part.  My story still holds;  if people see that
> we are playing games with the URL anyway, they may want CGI's handled in
> a special fashion.
> 
> > [ other musings snipped ]
> > > Of course here I have focused on CGI, the only contexts I run into that
> > > drive a URL to such lengths :)  Anyone have any long URL examples which
> > > are *not* CGIs?
> > 
> > I hope you are aware you cannot really reliably tell anything about 
> > CGI-or-not
> > from looking at an URL (not should you).
> 
> I did mention this earlier, didn't I, that unfortunately many CGI backends 
> take / to look just like regular URLs?  Or perhaps that ended up in trimmings.
> Oh well.  That's why the prompt...

Yes, you wrote something like that, but you are still assuming that
talking about "CGI's" makes sense here.  I say it doesn't.

> I'm sure you'll continue to excuse my lack of eloquence as I try to play
> devil's advocate.
> 
> >  
> > http://204.71.206.114/RealMedia/ads/click_lx.ads/www.salonmagazine.com/tech/content.html/274871250/Frame2/SalonShoppingBlowout/summerblowout125.gif/63666535393439643337616134353330
> 
> But of course, this is *not* a non-CGI URL, though it is an excellent example
> of one with no ? delimited query part.

All I know that the resource denoted by this URL is likely not realized
on the server as a direct mapping from a static file.  Beyond that, I
don't know whether the server uses the Common Gateway Interface, or NSAPI,
or ISAPI, or Java servlets, or Apache's mod_rewrite, or a homegrown
mod_push_those_ads_out.so, or three levels of internal proxy redirection,
or something similar, or Something Completely Different.

How do you know whether http://localhost/showenv is a "CGI URL" or not?
I'm afraid you have made that term up without a definition.  I would
not suggest to use it when you write to a webmaster, for example (unless
perhaps when you really *know* that CGI is being used).  

I hope you'll continue to excuse my nitpicking.  I do have the excuse
for it that it doesn't stray further from realistic things than split
statuslines and AI-like URL-pattern-recognition, which seems to be
where you are heading.

   Klaus