Re: COMMENT: LAST CALL comment

>>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.

What I said also applies to backslash.  To the extent that backslash
is used in any MIME or HTTP quoted-string (almost never), it *always*
means quote the next character.  It is therefore safer to require all
implementations to handle it as such than it is to stick our heads in
the sand and hope that no HTTP application ever needs to send one as 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.

As defined by the Content-Disposition requirements for MIME.

>>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.

Koen, that change received VERY careful consideration two years ago and
IS ALREADY a requirement of HTTP/1.1.  The only problem is that the BNF
is wrong and contradicts the text, and it is the BNF that will change.

>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.

It is irresponsible to complicate header field parsing when no problem
exists to require those complications.  Backwards compatibility hacks
exist to circumvent known problems, not imagined ones.

....Roy

Received on Sunday, 15 June 1997 18:24:09 UTC