W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997


From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Wed, 11 Jun 1997 14:58:40 -0700
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9706111458.aa20215@paris.ics.uci.edu>
>>> 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.

Received on Wednesday, 11 June 1997 15:09:03 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:44 EDT