- From: Koen Holtman <koen@win.tue.nl>
- Date: Sun, 15 Jun 1997 21:23:33 +0200 (MET DST)
- To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
- Cc: koen@win.tue.nl, http-wg@cuckoo.hpl.hp.com
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. >....Roy Koen.
Received on Sunday, 15 June 1997 12:25:17 UTC