Re: COMMENT: LAST CALL comment
Koen Holtman (koen@win.tue.nl)
Thu, 19 Jun 1997 20:59:06 +0200 (MET DST)
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.