>>> Interestingly, allowing quoted-pairs withing quoted-strings would bring
>>> HTTP's definition of media-type parameters back in line with MIME's.
>>> MIME relies on the RFC 822 definintion of quoted-string, which allows
>>> quoted-pairs, and "value" is defined in both HTTP and MIME as "token |
>>> quoted-string".
>>
>>In the world of computer science, the principal of no suprises would
>>dictate that the correct 'design' is quoted-pairs are supported.
>
>I would find such a change quite surprising. A stated principle of
>HTTP version numbering design is that messages with the same major
>version number will parse in the same way. So I would be surprised if
>quoted string parsing changed from 1.0 to 1.1.
Allowing quoted-pairs within quoted-strings does not change the HTTP
message parsing algorithm -- it only changes the parsing algorithm of
individual field values that are allowed to contain a double-quote
as a character. 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.
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.
....Roy