Re: Amaya mishandling HREF values that contain ampersand

On Wed, 7 Jul 1999, Andrew Pam wrote:

> >    href="http://host/?x=1&#38;y=2"> or <A 
> >    href="http://host/?x=1&amp;y=2">.
> >    
> >    We recommend that HTTP server implementors, and in particular, CGI
> >    implementors support the use of ";" in place of "&" to save authors
> >    the trouble of escaping "&" characters in this manner.

> This seems like a rather unfortunate design oversight in the HTML 4.0
> specification.

It's been like this since HTML2.0, indeed the above text seems to have
been copied verbatim from RFC1866 (see the end of section 8.2.1).

>  Using %26 is preferable 

Using %26 would seem to be a clear indication for the ampersand to be
included as part of the value text, rather than being treated as a
delimiter of the NAME=VALUE pair in the query string.

> because it doesn't rely on
> browsers correctly converting &amp; back to an ampersand, 

If you can't rely on browsers implementing the advertised
specification, then you'd be in the situation that we're currently in.
But changing the specification does not seem to be an appropriate
response to a bug in one browser - which admittedly a few other
browsers also had some years ago, but which they have now corrected
in accordance with the, stable, published specification.

> and the
> admonishment to replace the use of ampersand with semicolon in CGIs
> seems difficult to achieve without breaking compatibility with the
> urlencoding format for HTML forms!

The idea is that a script would accept both, thereby allowing the use
of either.

Is it really appropriate to discuss the design of HTML on a browser
list?  I'm responding briefly because the issue has been raised, but I
suspect this part of the discussion ought to be moved elsewhere.  The
only issue as far as Amaya is concerned seems to be that it is not
conforming to the published HTML spec, and that this is particularly
embarrassing to those of us who try to stand up for conformance to the
W3C's specifications.

best regards

Received on Tuesday, 6 July 1999 11:48:19 UTC