🚀 go-pugleaf

In article <6hupr9$hbj$1@samba.rahul.net>,
Doug Kaufman  <dkaufman@rahul.net> wrote:

>><a href="http://cgi.unicorn.us.com/cgi-bin/unicorn/mgadmin?getpswd=33536&lg=1">Miami (University of)</a>
>
>The problem is that lynx is interpreting the URL according to the html
>specification. You have invalid html on your web page, as you can see
>with one of the html validators.

No, my HTML is valid.  This has nothing to do with HTML specs, this is
about URI specs.  WebLint in pedantic mode found nothing wrong with my
URIs.  Neither the W3C validator nor NetMechanic found anything wrong
with my URIs either.

>The ampersand needs to be escaped.  Change the "&" to "&amp;" and all
>should work well.

This ampersand is an argument delimiter in a query string, not a
displayable character.  The URI specification says pretty clearly that
the ampersand is reserved as a delimiter when used within a query string.

Allow me to quote from "Uniform Resource Identifiers
(URI): Generic Syntax and Semantics", T. Berners-Lee,
R. Fielding, L. Masinter, 18 November 1997, at
http://www.ics.uci.edu/pub/ietf/uri/draft-fielding-uri-syntax-01.txt.

2.2. Reserved Characters

   Many URIs include components consisting of or DELIMITED BY, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"

   ...Characters in the "reserved" set are not reserved in all contexts.
   The set of characters actually reserved within any given URI
   component is defined by that component. In general, a character is
   reserved if the semantics of the URI changes if the character is
   replaced with its escaped US-ASCII encoding.

The ampersand is reserved as a delimiter in a query string.  If the data
contained within the query string needs an ampersand because the CGI
expects it, then that ampersand is not being used as a delimiter and
must be escaped.  Here's the description of the query component of the
URI:

4.3.3. Query Component

   The query component is a string of information to be interpreted by
   the resource.

      query         = *uric

   Within a query component, the characters "/", "&", "=", and "+" are
   reserved.

Lynx should transmit the query string "as is" without interpreting it.
I know of no spec that says a query string inside a URI is supposed
to be urldecoded by the browser before transmitting it!  Decoding the
query string is the CGI's job.  I maintain that this is a bug in Lynx.
A browser has no business decoding a urlencoded string inside a URI.

>Let me know if this doesn't fix the problem. Lynx is not trying to be
>a validator, but trying to interpret html accurately means that some
>invalid html is not rendered as the author intended.

The HTML is valid.  Changing my ampersands to &amp; did cause Lynx to
use the URL correctly.  However, I am suspicious that this fix works
only for Lynx, and not for other browsers.

In any case, it's pretty clear that this is a bug in Lynx.  It is
interpreting the ampersand the same way throughout the page regardless
of the context.  My web pages conform to the specs, far as I can tell.

-Alex