Re: LYNX-DEV ac0.97: CGI &-separated parameters are broken now.

[Klaus Weide]

On Tue, 2 Dec 1997, address@hidden wrote:
> On Mon, 1 Dec 1997, Klaus Weide wrote:
> 
> > > First obvious error is that Lynx violates HTML specs here trying to parse
> > > &-entity without final ";"
> > 
> > If you want to claim that that is an "obvious error", you have to provide
> > some references to support that claim.  It certainly isn't obvious to me.
> 
> The SGML entiry must end with ";" per SGML definition and DTD.
> I.e. only ⟨ must cause reaction, not just &lang 

Nope.  See RFC 1866 3.2.1, especially

   The terminating semicolon on entity or numeric character references
   is only necessary when the character following the reference would
   otherwise be recognized as part of the name (see 9.4.5 "Reference
   End" in [SGML]).

> > I expect that (new) Lynx is not the only client that tries to expand
> > entities in HREF (and similar) attributes (as required by SGML).
> > Even if other browsers currently don't do it, they may do so in the
> > future.  So don't just blame Lynx.
> 
> I blame not for expanding but for wrong "guessing". How do you treat
> &language f.e.? It impossible to do expanding correctly without final ";"
> and lynx must not do it.

The entity reference ends with the first character that isn't
an ASCII letter or digit.  That "&lang", a substring of "&language",
happens to be a HTML 4.0 entity is irrelevant for parsing "&language"
(except in older Netscape clients, of course...).

There is no guessing involved.  Expanding entities only in some CDATA
attribute values, or only expanding them if followed by ';' (as you seem
to propose), would be guessing.

> I know that Netscape was first who broke SGML by trying to "guess"
> &xxx entries, but now even Netscape refuse parsing of &xxx entities
> without final ";" and left them intact, lets not be worse than they are.

What Netscape's older clients do is something quite different from what
Lynx does.

If you have used KGV (<URL:http://ugweb.cs.ualberta.ca/~gerald/validate/>)
or Webtechs (<URL:http://www.webtechs.com/html-val-svc/>) with "Treat URL
Ampersands" unchecked for validation, you should know that they complain
about such apparent entity references in HREFs.  Read the explanation at
<URL:http://www.cs.duke.edu/~dsb/kgv-faq/errors.html#bad-entity>, and
follow the link to RFC 1866 at the end.


     Klaus