W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

RFC2231 encoding in HTTP: whitespace handling

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 27 Aug 2008 16:26:23 +0200
Message-ID: <48B5640F.5000907@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>

Hi,

as discussed last week I have been working on a test suite checking the 
UA support of RFC2231 encoding -- <http://greenbytes.de/tech/tc2231/>.

One thing I wasn't sure about in 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html> 
was where exactly it makes sense to allow whitespace around the 
parameter value assignment -- which, as far as I can tell, is not really 
clear from RFC 2231.

Consider these test cases:

(1) Content-Disposition: attachment; filename *=UTF-8''foo-%c3%a4.html

(2) Content-Disposition: attachment; filename*= UTF-8''foo-%c3%a4.html

(3) Content-Disposition: attachment; filename* =UTF-8''foo-%c3%a4.html

(<http://greenbytes.de/tech/tc2231/#attwithfn2231ws1>, 
<http://greenbytes.de/tech/tc2231/#attwithfn2231ws2>, 
http://greenbytes.de/tech/tc2231/#attwithfn2231ws3>)

Both Opera and FF understand variants (2) and (3), but FF chokes on (1).

For my RFC2231-in-http proposal I see several choices:

a) conservative -- do not allow whitespace in or around the assignment; 
this is interoperable, and I really don't see why one would *want* to 
add whitespace,

b) pragmatic -- allow exactly those cases where interoperability is there,

c) ambitious -- allow all cases, and hope that implementations will be 
fixed and become interoperable.

For now I'm leaning to a) in the spirit of keeping things as simple as 
possible.

BR, Julian
Received on Wednesday, 27 August 2008 14:27:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT