In a recent note, Bob Izenberg said: > Date: Sat, 06 May 2000 21:39:14 -0500 > > > viewing any html document (remote or local, doesn't matter) with a > > link URL containing spaces, they will be removed. That is: > > > > <a href=3D"path with/spaces in it/index.html"> > > > > 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 :-). > > > > 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. >From RFC 1738: Octets must be encoded if they have no corresponding graphic character within the US-ASCII coded character set, if the use of the corresponding character is unsafe, or if the corresponding character is reserved for some other interpretation within the particular URL scheme. [ ... ] Unsafe: Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. It's clear that the intent of this is to require encoding of spaces in the source document and to permit Lynx's behavior. That said, the question remains; just because Lynx is allowed to behave as it does, should it? -- gil -- StorageTek INFORMATION made POWERFUL ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
