Multipart not being parsed; not appearing in request details

[mydoghasworms]

Most of the details of this issue are visible here: http://stackoverflow.com/questions/23953118/how-do-i-access-multipart-form-data-in-sinatra

Basically, I am receiving multipart/form data from a client, and the body has the following:

--KoZIhvcNAQcB
Content-Disposition: form-data; filename="1"
X-compId: 1
Content-Length: 1024

J0oLmc5Kpuf  5fART7gwqzPoaX2J0
... (some lines omitted)

--KoZIhvcNAQcB--

The content type header has: multipart/form-data; boundary=KoZIhvcNAQcB

However, this data is not being parsed, and does not appear in the request parameters. I am wondering if these are unsupported headers in the multipart data.

[mydoghasworms]

Just as a matter of interest, I have tried the same with WEBrick and Thin, and the result is the same.

[mydoghasworms]

Here is a sample of a complete POST request. Sorry if the formatting is wonky, I copied it out of a Windows terminal: http://pastebin.com/u6hZ7snS

[mydoghasworms]

I have gone one better by uploading an extract from my Thin server log, which you can view here: https://copy.com/ztlGA7QwzyFh

[renholm]

Are you by any chance doing the request from IE11? I've found issues with file uploads specifically from IE11. Maybe a separate issue.

[mydoghasworms]

@renholm No, the user agent in this case is an SAP system. But if you look at the request I have posted in the link earlier, it looks pretty normal, at least to my untrained eye.

[raggi]

From RFC2388: Each field has a name. Within a given form, the names are unique. and The relationship of the ordering of fields within a form and the ordering of returned values within "multipart/form-data" is not defined by this specification, nor is the handling of the case where a form has multiple fields with the same name.

As much as our multipart parser does suck, this use case is invalid AFAICS (although the RFC is vague, as it does not provide any RFC2119 terms in this area).

What do you expect me to do in this area? We also have a case where IE11 is not providing a filename parameter, and I cannot support all of these cases in a sane way in concert.

I would file a bug with SAP, as this client behavior is unusual and incorrect. In the meantime, we can keep trying to come up with a solution, if you have any ideas.

[raggi]

FTR: I'd really appreciate someone taking the time to write a standalone multipart parser that Rack could depend on, complete with client heuristics and a full test suite. It's a huge pain in my ass every time a new client comes along and badly implements an already bad RFC.

[mydoghasworms]

@raggi Thanks for the feedback. However, looking at the sample I posted, the names are unique: filename="1", filename="2", etc. Can you please be more specific as to how you mean the sample does not comply with the specification?
What I do see in section 4.4 of RFC2388, is:

The original local file name may be supplied as well, either as a
"filename" parameter either of the "content-disposition: form-data"
header or, in the case of multiple files, in a "content-disposition:
file" header of the subpart.

Which implies that the header of each section should be Content-Disposition: file; and not Content-Disposition: form-data;

Is this what you are referring to?

[raggi]

It's not the filename field, it's the lack of the name field, which normally corresponds to an <input> element in an HTML form use case.

What I'm thinking for this is making a change such that when the name field is missing, I'll just use the filename field, but there are some side effects to this direction.