Rack multipart - Content-Type implies File IO? (6674f365)

[Jonathan del Strother]

Heya,

I upgraded to Rack 1.0 recently and ran into some problems with our
client app uploading multipart form data.
The app uploads a file along with bunch of string parameters, with
each string's multipart section marked as "Content-Type: text/plain;
charset=utf-8". This used to work fine - rails would see the params
as a hash of strings, and a File object for the file.

http://github.com/rack/rack/commit/6674f3652ed19136802a0b84f1923f0b78052442
changed this behaviour - because the strings have a Content-Type, even
though they're just text/plain, they become File objects.

Is this the correct behaviour? It certainly surprised me - since text/
plain is the default content type, I would have thought that re-
specifying it would have no effect (that said, we are specifying a
charset, which I guess changes things a little).


( On a related note : I notice that Safari & Firefox don't specify a
content type on form fields. If I enter a bunch of japanese
characters into a form, how does rack correctly decode those given
they won't fit into the default US-ASCII character set?)


-Jonathan del Strother

[Jürgen Mangler]

Hmm, I perceive this behaviour as correct. Of course all rfc's need a
bit of interpretation. http://www.faqs.org/rfcs/rfc2388.html:

* Files have a content-type, the default content type is text/plain.
* Parameters have no content-type.

<quote>
As with all multipart MIME types, each part has an optional
"Content-Type", which defaults to text/plain. If the contents of a
file are returned via filling out a form, then the file input is
identified as the appropriate media type, if known, or
"application/octet-stream".
</quote>

Browsers definitely do it like this. Curl does it like this. net/http
with multipart addon does it like this. What lib does your client app use?

Jürgen

On 19.05.2009 11:17, Jonathan del Strother wrote:
> Heya,
>
> I upgraded to Rack 1.0 recently and ran into some problems with our
> client app uploading multipart form data.
> The app uploads a file along with bunch of string parameters, with
> each string's multipart section marked as "Content-Type: text/plain;
> charset=utf-8". This used to work fine - rails would see the params
> as a hash of strings, and a File object for the file.
>
> http://github.com/rack/rack/commit/6674f3652ed19136802a0b84f1923f0b78052442
> changed this behaviour - because the strings have a Content-Type, even
> though they're just text/plain, they become File objects.
>
> Is this the correct behaviour? It certainly surprised me - since text/
> plain is the default content type, I would have thought that re-
> specifying it would have no effect (that said, we are specifying a
> charset, which I guess changes things a little).
>
>

> ( On a related note : I notice that Safari& Firefox don't specify a

[Jonathan del Strother]

Thanks for the response. However, I don't see where you're inferring
'parameters have no content type' from. Section 4.5 of that RFC says:

Each part of a multipart/form-data is supposed to have a content-
type. In the case where a field element is text, the charset
parameter for the text indicates the character encoding used.

> What lib does your client app use?

Our app uses a home-built http library, unfortunately. Pretty sure it
follows the specs fairly well, but the specs and real world seem to be
2 very different things...


On May 19, 11:18 am, Jürgen Mangler <juergen.mang...@univie.ac.at>
wrote:

> Hmm, I perceive this behaviour as correct. Of course all rfc's need a

> bit of interpretation.http://www.faqs.org/rfcs/rfc2388.html:

>
> * Files have a content-type, the default content type is text/plain.
> * Parameters have no content-type.
>
> <quote>
> As with all multipart MIME types, each part has an optional
> "Content-Type", which defaults to text/plain.  If the contents of a
> file are returned via filling out a form, then the file input is
> identified as the appropriate media type, if known, or
> "application/octet-stream".
> </quote>
>
> Browsers definitely do it like this. Curl does it like this. net/http
> with multipart addon does it like this. What lib does your client app use?
>
> Jürgen
>
> On 19.05.2009 11:17, Jonathan del Strother wrote:
>
>
>
> > Heya,
>
> > I upgraded to Rack 1.0 recently and ran into some problems with our
> > client app uploading multipart form data.
> > The app uploads a file along with bunch of string parameters, with
> > each string's multipart section marked as "Content-Type: text/plain;
> > charset=utf-8".  This used to work fine - rails would see the params
> > as a hash of strings, and a File object for the file.
>

> >http://github.com/rack/rack/commit/6674f3652ed19136802a0b84f1923f0b78...

[curu...@gmail.com]

I will think (and talk to others) about this, and provide a patch if
plausible.

* Fact is that browsers and most(!) library's don't do it like you
describe.
* Now the presence of a content-type leads to File object.

* Maybe (and i'm not sure about this) its better anyway that you get a
binary file with encoding,
because rack does imho not handle encodings for multiparts. it uses
the encoding specified in the main headers. Who knows what happens.

If nobody else complains i think it would better to leave it like it
is, because then uploaded text files are really files.

Jürgen

[Jonathan del Strother]

I'd agree that uploaded text files definitely ought to come out as
File objects rather than their strings, but I'd argue that the
presence of a 'filename' parameter in the content-disposition field
ought to be used to check for that.

You might be right about the encoding issue, though. Personally I'd
expect to see rack just interpret the text in the given encoding. It
seems like a browser would be perfectly entitled to start sending
Content-Type on multipart form fields containing non-ascii characters,
which would then break any rack based apps that assume their form
field values will just be strings.