Re: LYNX-DEV Relative URLs, BASE implementation

[Klaus Weide]

Fote,

 Thanks for a lot of information, and for the reality check re relative
URLs.  My understanding was based, on little more than reading RFC 1808,
and as you are shown, there are good reasons why Lynx deviates from 
that: 

[about <params>:]
> [...] on today's Web, treating
> anything but ;type= in ftp URLs as a parameter, with checks for that
> really being what it appears, is likely to result in failure to fetch
> the intended document.

[about <query>:]
> [...] to change it would require
> redesigns of the FORM handling, ISINDEX handling, gopher gateway, and
> wais gateway, and no one has reported any problems in the "real world"
> after all these years, so...

[and also about <fragments>, omitted.]

There are still some remaining cases which you didn't cover -
some I would think are bugs (Lynx shouldn't try to eliminate
/./ out of ?query and #fragment parts - or is that also for 
compatibility?) and some are about whether a slash is retained 
after a final /. or /.. has been eliminated.  The latter could be
important if further resolutions are based on it... because then
it is important whether the base URL ends with a slash... but relative
URLs ending in /. or /.. are probably not a normal thing in HTML pages.

DIRED mode is behaving rather oddly w.r.t ../ paths (and in other ways
too), but I haven't figured out yet whether that is related.

> [about ../ at beginning of path:] 
> [...]  Servers should
> be set up themselves to avoid spoofing via relative specs.  Where it
> might matter, is for file URLs, and HTML.c has quite a bit of code for
> modifying the resolution of file URLs, and permits context dependent
> decisions about simplification.  It seems better to keep that in
> HTML.c than to do it indescriminately in the HTParse.c functions.

OK... (and I guess I should look at it.) 

[about other topics:]
>       Lynx uses only the HTTranslate() function in HTRules.c, which at
> present is very small (has no effect on the image worth worrying about)
> and doesn't change anything (need not be called).  However, redirection
> the way Lou had originally designed it, was being done in HTMIME.c,
> after commitments that caused unsolveable memory leaks, and unsolveable
> security risks (e.g., Lynx could be redirected to URLs or actions that
> were configured to be disallowed).  My mods are fine for HTTP/1.0
> but have the disadvantage of ad hoc MIME header parsing in HTTP.c, and
> sending you back to LYGetfile.c to, in effect, start all over again
> with non-conventional security checks.  

Well, to quote from HTAccess.c: "This may seem bizarre, but it works
like a charm! - FM" :-)

> To make new HTTP/1.1 stuff really
> work well, it might be better to use server-like rules and configuation
> files, and more of the libwww5's code for access regulation and security
> checks.  

According to the new libwww's architecture, one would do these as
"Filters".  The Filters could be based on HTRules, or could just be
any code (that does some stuff and then returns a different code for
"allowed" or "forbidden").  It would probably be more straightforward 
to convert the currently existing checks in LYGetFile.c (and further
down) to the latter form.

But, sure, rules files sounds good.  "Use your existing CERN server
configuration file for Lynx without changing it." :)
 
>          So I don't personally want to change things in the libwww-FM
> that might promote others taking us further down a hacker's and perhaps
> ultimately dead-end road.  Using server-like files means that things
> like caching could be regulated properly, reliably, and based on whether
> Lynx is being run on a strained multiuser system or powerful personal
> computer. You would want the select()-based threading for many of the
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> features you'd use on a powerful personal computer, and there's no
  ^^^^^^^^
> way to predict at this point how much performance would be affected.

Maybe I got too used to Lynx, but what are those features?
This is a serious question.  The scrolling-while-Lynx-is-retrieving-next-file
comes to mind, but otherwise I cannot come up with much that is seriously
missing (or that I miss) that wouldn't require a gooey browser anyway.

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;