W3C home > Mailing lists > Public > www-amaya@w3.org > July to September 1999

Re: Summary: Amaya mishandling HREF values that contain ampersand

From: <Irene.Vatton@inrialpes.fr>
Date: Fri, 09 Jul 1999 09:15:25 +0200
Message-Id: <199907090715.JAA18777@tahiti.inrialpes.fr>
To: Bertrand.Ibrahim@cui.unige.ch
cc: www-amaya@w3.org
In-reply-to: Your message of Thu, 08 Jul 1999 18:35:52 +0200."
             <0FEK00DCZ8RTLB@cuimail.unige.ch> 
> jose.kahan@w3.org said:
> > If we're making a local file access, we'll then first convert the %26
> > into '&' then do search the file
> 
> I guess you're assuming that, in this case, the '&' will be part of a file 
> or directory name, not a field separator in the <searchpart>. Indeed, if you 
> look at RFC 1738, section 5 (BNF for specific URL schemes), you find:

Obviously yes.

>   fileurl        = "file://" [ host | "localhost" ] "/" fpath
> 
> and
> 
>   fpath          = fsegment *[ "/" fsegment ]
>   fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
> 
> In addition, section 3.10, describing the file URL scheme, says:
> 
>  "A file URL takes the form:
> 
>     file://<host>/<path>
> 
>   ...   <path> is a hierarchical
>    directory path of the form <directory>/<directory>/.../<name>."
> 
> I interpret this as meaning that a file URL can contain unreserved characters
> or escaped characters or any of '?', ':', '@', '&' and '='. All these 
> characters will be considered as part of a directory name or a file name.

When a URL which contains a '&' is stored within a HREF attribute it has to be
encoded either by &amp; or by %26.

  Irene.
Received on Friday, 9 July 1999 03:15:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 April 2014 11:01:32 UTC