- 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
>>> 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
Received on Wednesday, 11 June 1997 15:09:03 UTC