Re: COMMENT: LAST CALL comment

Roy T. Fielding:
> [Koen Holtman:]
>>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.

Well, as my example below shows, Netscape 3.01 does *not* use the rule
that backslash *always* means quote the next character.

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

My point was that NS 3.01 did not intepret the \ as quoting the next
character.  If it had, the requester would have shown blah" or blah_,
at least something without an underscore at the start.

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

To put it bluntly, this VERY careful consideration two years ago is not
careful enough for me.  I would like to see measurements of current
practice which show that little will break if we make this change.

I would be very happy if someone who has a lot of raw proxy traces
could grep them for the occurence of \ in quoted strings.

>....Roy

Koen.

Received on Thursday, 19 June 1997 12:02:59 UTC