Subject: RFC2231 encoding in HTTP: whitespace handling

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Aug 2008 16:26:23 +0200

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 28 Aug 2008 03:31:46 +0200

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

I think FF got this right.  "*" is supposed to stick to the name,
not to the "=".  This also simplifies the ABNF-ication with EQU 
for all cases of "=".

 Frank
-- 
Cc: to Ned, likely he still knows how *= was designed in RFC 2231.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Aug 2008 09:24:45 +0200

> not to the "=".  This also simplifies the ABNF-ication with EQU 

Can you point to language or ABNF rules in RFC2231 or MIME that actually 
says that (I'm ready to believe you, I just want to understand how you 
come to that conclusion...).

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 28 Aug 2008 10:20:56 +0000

Julian Reschke wrote:

> Can you point to language or ABNF rules in RFC2231 or MIME
> that actually says that (I'm ready to believe you, I just
> want to understand how you come to that conclusion...).

It's a bit tricky, that's why I sent a copy to Ned.

"*" is no <tspecials> in RFC 2045.  A lexical parser handles
it as ordinary token character.

"*" is also no <specials> in RFC 5232 (2822upd).  A lexical
parser handles it as ordinary <atext> character.

RFC 2231 does not update <tspecials>.  In fact it says:

| Specifically, an asterisk at the end of a parameter name
| acts as an indicator that character set and language
| information may appear at the beginning of the parameter
| value.

"At the end of" is arguably not the same as "following".
Not the same situation as for "=", where RFC 2045 states:

| Note that the definition of "tspecials" is the same as
| the RFC 822 definition of "specials" with the addition
| of the three characters "/", "?", and "=", and the
| removal of ".".

But I'm far from sure that my interpretation is okay...

 Frank