lynx-dev Query string handling bug vs bad html

[Foteos Macrides]

Doug wrote:
>A user of my copy of lynx2.8.1dev6 on rahul.net has complained that
>there is a bug in handling ampersands used as delimiters in query
>strings in URL's. I replied that the ampersands needed to be escaped
>as "&", but he replied that the need for escaping is outside of
>the specifications. I would appreciate comments on whether this is a
>lynx bug or invalid html. The question is outside of the area of my
>expertise. If I gave bad advice, I would like to make a retraction.
>Please see the test URL at the end of this message.

        I read that exchange in the newsgroup, and Alan Flavell gave
him the correct answer, but it still didn't sink in to him.  The URL
specs describe the character restictions for URLs in the abstract,
and additional restrictions can apply in specific contexts.  When
URLs appear in text/html as attribute values, the HTML (actually,
SGML) restrictions for allowed characters in those values also apply,
and an ampersand should be SGML escaped (&) if it does not
introduce a named or numeric character reference.  The query in
question includes &gl= and the = acts as an implied terminator, so
that is treated as ≷= and Lynx recognizes the gl as a named
character reference, whereas what's intended is &gl= which would
be handled as &gl= on SGML unescaping.  If what follows the ampersand
does not correspond to a known character reference, then Lynx uses
the error recovery of retaining the ampersand as a raw character, and
that is what he wants Lynx to do always, rather than accepting that
he needs to understand the HTML specs as well, and not rely solely on
the URL specs without regard to context.

                                Fote
-- 
Foteos Macrides (address@hidden during April, '98)