W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997


From: Koen Holtman <koen@win.tue.nl>
Date: Sun, 15 Jun 1997 21:23:33 +0200 (MET DST)
Message-Id: <199706151923.VAA02828@wsooti08.win.tue.nl>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3536
Roy T. Fielding:
>Since there are no such field values defined by HTTP/1.0
>(quoted-strings are either URLs or IANA parameters in HTTP/1.0),
>there is no known parsing conflict between the two versions, and any
>unknown parsing conflict would imply that the system is attempting
>to pass double-quote as data and therefore outside the scope of HTTP/1.0.

I don't think it is as easy is that.

How about this for a parsing conflict:

 Content-type: application/applefile; name="\blah\"

Note that the system is not passing double-quote data.

I just tried sending a response with

 Content-Type: application/octet-stream
 Content-Disposition: attachment; filename="\blah\"      

to a Netscape 3.01, and it pops up a requester with _blah_ (the
backquotes are transformed into underscores, presumably for security
reasons) as the filename.

>The simple fact of the matter is that there was no defined way for new
>fields containing quoted-strings to include the double-quote within the
>data content of that string.  I needed to define one or disallow
>double-quote in all supposedly-opaque strings.

I think this issue needs very careful consideration before we can
proceed.  If we go for double-quotes, I think that we at least need to
put some large warnings about the change in quoting style in the spec.

Maybe the easiest way out is to define two types of quoted-string, one
1.0 style and one 1.1 style, and to use the 1.1 style one only in new
1.1 headers.


Received on Sunday, 15 June 1997 12:25:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC