Subject: Re: draft-reschke-rfc2231-in-http-02

From: Julian Reschke <[email-masked]>
Date: Tue, 04 Aug 2009 13:47:49 +0200

Daniel Stenberg wrote:
> Hello,
> 
> (While I know Julian Reschke's work on the revised RFC2231 for HTTP 
> isn't exactly a HTTPbis topic, I hope you bear with me for abusing this 
> list a little since it doesn't really have any other home afaik.)
> 
> As I mentioned on the HTTPbis meeting at IETF75 in Stockholm, I recently 
> came to think about the Content-Disposition header in HTTP multipart 
> upload streams [RFC1867 - Form-based File Upload in HTML] and even 
> though I guess those headers are more strictly MIME than the 
> Content-Disposition in a HTTP response, it wouldn't surprise me the 
> least if browsers deal with them identically (and possibly receivers of 
> RFC1867 will also parse them HTTP-style and not MIME-style). Some 
> feedback on that would of course be very interesting.
> ...

Hi Daniel,

thanks for the feedback. I just spent a few minutes investigating 
further, and what I found out is:

- RFC1867 is obsoleted by RFC 2854

- the latter refers to RFC 2388 for the multipart MIME type (confirmed 
in <http://www.iana.org/assignments/media-types/multipart/>)

- RFC 2388 seems to be a bit confused about what encoding to use, it 
mentions both RFC 2047 (which I think is a bug), RFC 2184 and RFC 2231 
(2231 obsoleted 2184) -- I think this should be addressed with an 
erratum (Larry, are you reading this...?)

Implementations:

- the Apache commons fileupload library doesn't seem to attempt to 
handle either RFC 2047 nor RFC 2231 encoding

- IE appears to send non-ASCII characters as raw ISO, at least if the 
source page used that encoding,

- Firefox appears to escape with &#ddd; notation.

So this seems to be a mess.

BR, Julian

> Apart from that, I believe the Julian's draft works perfectly well for 
> all purposes I can think of. I have no complaints or remarks.
>

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 4 Aug 2009 14:10:42 +0200 (CEST)

> - RFC1867 is obsoleted by RFC 2854

Oh, thanks, I hadn't noticed. But I think would rather say that technically it 
has been obsoleted in parts by RFC 2854 and in parts by RFC 2388.

> mentions both RFC 2047 (which I think is a bug), RFC 2184 and RFC 2231 (2231 
> obsoleted 2184) -- I think this should be addressed with an erratum (Larry, 
> are you reading this...?)

Right, but no matter which MIME specs it should refer to it considers the 
headers to be MIME (as opposed to HTTP-like). Thus it seems RFC2231 _should_ 
be our guide.

> - the Apache commons fileupload library doesn't seem to attempt to handle 
> either RFC 2047 nor RFC 2231 encoding

So how does byte codes within file names above 128 get included? Or are those 
bytes just skipped?

> - IE appears to send non-ASCII characters as raw ISO, at least if the source 
> page used that encoding,

This is similar to what curl currently does and what initiated my 
investigation into this area. It simply has no notion of encoding and passes 
on whatever the user pass in as "file name".

Someone detected that curl thus didn't do the upload the same way one of the 
browser did. Now I realize it will be hard to mimic those without getting my 
brain to hurt...

> - Firefox appears to escape with &#ddd; notation.

I have a hard time to see how HTML encoding can be the right thing here.

-- 

  / daniel.haxx.se