lynx-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev bug report

From: Klaus Weide
Subject: Re: lynx-dev bug report
Date: Mon, 25 Oct 1999 15:38:29 -0500 (CDT) 
On Mon, 25 Oct 1999, Oliver Seidel wrote:

> Hello,
> 
> > Please give a full example, for at least one file, with no "..." or "X",
> > of
> > 
> >    - the filename (as shown by ls)
> 
> ~~$ ls -lR test
> total 5
> -rw-r--r--   1 os10000  private      3689 Oct 25 11:10 
> forum_reply?keepcookie=0&lm=854576442
> drwxr-xr-x   2 os10000  private       512 Oct 25 11:12 hall_of_fame
> 
> test/hall_of_fame:
> total 18
> -rw-r--r--   1 os10000  private     18310 Oct 25 11:10 index.html
> 
> >    - the string that you are using to try to access that file, and its
> >      context.  If I understand right that would be a link in an HTML
> >      file created by wget.
> 
> ~~$ head test/hall_of_fame/index.html 
> <HTML><HEAD><TITLE>Forum 2000</TITLE></HEAD>
> <BODY BGCOLOR="#ffffff" TEXT="#000000">
> <center>
> <img src="../../TrinaryEncodings/HallOfFame.jpg" width=567 height=66></center>
> <br clear=all>
> <HR>
> <TABLE>
> <TR><TD><A HREF="../forum_reply?keepcookie=0&amp;lm=854576442">How much wood 
> would a wood chuck ch...</A><TD>1 day old<TD>(last of 9 replies 998 days 
> ago)</TR>

Ok that's enough to see. :)

Well, Lynx is right to interpret the "&amp;" within the HREF attribute
string as standing for an "&" in the URL.  Not doing so would be broken.
(As broken as wget is, it seems.)

Most browsers theses days should act this way.

Well, I see wget did "Convert the non-relative links to relative ones
locally", that is what I see the -k flag is documented to do.  The
documentation doesn't make any claim that those converted links will
actually be usable to access the corresponding downloaded files...

But the filename wget chooses just doesn't make sense.

Now if the filename were
   forum_reply?keepcookie=0&lm=854576442
and the HTML document had
   HREF="../forum_reply?keepcookie=0&amp;lm=854576442"  (as before)
acces should work with lynx.  A "&" in a filename should be escaped
*at the URL level* as "%26", but lynx isn't picky about that.  Some
other browsers (or other consumers of URLs) may be, for whom a "&"
character in a file UR may actually have a syntactic function.
(I am thinking about stuff like passing CGI-like arguments to embedded
scripts in local files.)

Now if the filename where
   forum_reply?keepcookie=0&lm=854576442
and the HTML document had
   HREF="../forum_reply?keepcookie=0&lm=854576442"
acces form lynx would also work.  (Error recovery, in this case that's
ok since there is no defined "&lm;" character entity.)

Now if the filename really is
   forum_reply?keepcookie=0&amp;lm=854576442 (as it is)
then a HREF in an HTML document would have to look like this:
   HREF="../forum_reply?keepcookie=0&amp;amp;lm=854576442".
Or, better,
   HREF="../forum_reply?keepcookie=0%26amp%3Blm=854576442".



On a different topic,

> > > I have added the line "SUFFIX::text/html" to my lynx.cfg file so that the
> > I'm surprised...  Are you sure that has an effect?
> 
> no I wouldn't want to claim that has an effect.

I tried it, and it actually seems to work as making some files
treated as text/html.  I haven't checked which ones exactly
(like whether it overrides other suffixes, how it depends on order).

(In the latest 2.8.3dev.13 there's extended SUFFIX syntax which should
allow you to do somethink like that in a more documented way.)

   Klaus
reply via email to
[Prev in Thread] Current Thread [Next in Thread]