Re: lynx-dev Lynx removes spaces in URLs

[Klaus Weide]

On Sat, 6 May 2000, Bob Izenberg wrote:

> [ Message forwarded from un-subscribed address
>   address@hidden ]
> 
> > Hi list,
> > 
> > I tried to send this to the list a few weeks ago or so, but it
> > turned out one has to be subscribed in order to be able to post,
> > and there was some other trouble.  Now I'm subscribed, so I'll
> > post it again.

Apparently not yet (therefore cc'd).

> > This means that the bug discussed below might have
> > been fixed since then.

Nope; and it's not a bug.

> > It exists in 'Lynx 2.8.3pre.4 (11 Apr
> > 2000)'.  I'm using Redhat Linux 6.1 on intel x86 hardware, if
> > that's of any use to you.
> > 
> > Okay, the problem.  I searched the list archives without finding
> > any discussions about this, so here goes...  It seems that when
> > viewing any html document (remote or local, doesn't matter) with a
> > link URL containing spaces, they will be removed.  That is:
> > 
> > <a href="path with/spaces in it/index.html">

That is no a valid HREF attribute value, since it does not contain a
valid (relative) URL-reference.  Somebody else already responded with
quotes from an RFC 1738.  <http://www.ietf.org/rfc/rfc2396.txt> is
newer, but doesn't change anything significant in this regard.

> > Will be interpreted as "pathwith/spacesinit/index.html" by lynx.
> > This is the URL it will show on the status line (in 'expert' user
> > mode), and send to the server when one tries to follow the link.
> > The major problem is that in its present state, lynx is unable to
> > navigate several web sites (especially those with auto-generated
> > directory listings) that I frequent, which is a bit annoying :-).

Those sites are broken.  More specifically, whatever auto-generates those
listings without proper URL-encoding is broken.

> > I think (I might be wrong) that the correct behaviour would be not
> > to modify anything internally, and then quote spaces as "%20" only
> > when needed -- in particular, in HTTP requests.

There is no prescribed correct behavior here - whatever a client does
with it is error recovery.

But anyway, when exactly are valid URLs "needed"?  Definitely in HTTP
requests, but what about all the other occurences of URLs, including in
Lynx-generated pages, including bookmarks etc. (and I definitely wouldn't
like to make lynx *generate* more invalid HTML).  Your suggestion implies
that lynx has to handle URLs internally in 2 forms (1. valid, 2. "fixed up"),
keep track of which is needed where, and/or convert appropriately.
Much easier to have only one internal representation, and convert to
that when parsing.

> > As far as I can
> > see, this would work much better in every way than the present
> > behavior. 

- It would further encourage the use of invalid documents.

> > Regardless of which behaviour is the True and Proper
> > one, there is a problem here, so IMHO if it's not going to be
> > fixed it deserves a compatibility option in lynx.cfg -- since
> > there are a whole lot of convenient flags for broken html and
> > stuff in there already.  But that's *my* opinion -- you're the
> > experts :-).

It is a reasonable wish, but I don't find it very desirable to
add such a yet-another-deal-with-broken-sites option.

> > On a side note, when viewing directory listings generated
> > internally by lynx, such as on the local filesystem or on ftp
> > sites, lynx "cheats" by writing links such as:
> > 
> > <a href=3D"path%20with/spaces%20in%20it/index.html">
> > 
> > ...  And therefore the problem mentioned doesn't occur.

This isn't cheating at all - it's exactly how things are supposed
to be done.  Whoever converts from file syntax to URL-syntax
has to take care of generating proper URLs.  In the case of local
directory listings, that's obviously lynx itself.  Ditto for FTP
(although I don't know how well filenames with spaces work for FTP).



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden