Failure to recognise 'valid' form data from iPhone

[Tim]

Hi,

I have written a simple API in ASP.Net (VB) .Net framework 3.5 for an iPhone
application to integrate to our customers product. This includes uploading
pictures and audio files using 'multipart/form-data'....

On some iPhones it works fine (inc the developers) but on others it fails as
ASP fails to recognise the data as a form (i.e. Request.Form.Count is 0)

I believe this is due to the fact that on the failing iPhones the boundary
definition is not at the end of the content-type line or doesnt have double
quotes around.

i.e. This is a working Content-Type
'multipart/form-data; charset=utf-8; boundary=0xKhTmLbOuNdArY'

This is the failing version
'multipart/form-data;boundary=0xKhTmLbOuNdArY; charset=utf-8'

I've failed to get the iPhone developer to try to make sure the boundary is
at the end of the line, remove the charset, or to put double quotes around
the boundary (I think that would work).

Unfortunately when I tried to use specification to back up how ASP was
working I found that it looks like ASP may be wrong? RFC 2046, section 5.1.1:
does not include the ";" as a valid boundary character so I would expect it
to still recognise it as the section termination. However I cant find
anything definitive on this behaviour.

So my questions are:
[1] Is ASP handling this correctly or not and if so by what spec/rfc?
[2] Is there a way to get ASP to recognise this input without parsing the
total content stream myself?

Cheers

 

[Tim]

Additional data on examples

Working version: Content-Type and data stream dump (partial)
'multipart/form-data; charset=utf-8; boundary=0xKhTmLbOuNdArY'
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="mailboxid"

123465
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="pin"

1234
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="function"

UploadPhoto
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="file"; filename="Profile.jpg"
Content-Type: application/octet-stream; charset=utf-8


Failing version: Content-Type and data stream dump (partial)
'multipart/form-data;boundary=0xKhTmLbOuNdArY; charset=utf-8'

--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="mailboxid"

123456
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="pin"

1234
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="function"

UploadPhoto
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="file"; filename="Profile.jpg"
Content-Type: application/octet-stream; charset=utf-8


Note: File data removed and actual data numbers changed

 

[Tim]

Additional data on examples

Working version: Content-Type and data stream dump (partial)
'multipart/form-data; charset=utf-8; boundary=0xKhTmLbOuNdArY'
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="mailboxid"

123465
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="pin"

1234
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="function"

UploadPhoto
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="file"; filename="Profile.jpg"
Content-Type: application/octet-stream; charset=utf-8


Failing version: Content-Type and data stream dump (partial)
'multipart/form-data;boundary=0xKhTmLbOuNdArY; charset=utf-8'

--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="mailboxid"

123456
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="pin"

1234
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="function"

UploadPhoto
--0xKhTmLbOuNdArY
Content-Disposition: form-data; name="file"; filename="Profile.jpg"
Content-Type: application/octet-stream; charset=utf-8


Note: File data removed and actual data numbers changed

 

[Patrice]

Hello,

Unfortunately when I tried to use specification to back up how ASP was
working I found that it looks like ASP may be wrong? RFC 2046, section
5.1.1:
does not include the ";" as a valid boundary character so I would expect
it
to still recognise it as the section termination. However I cant find
anything definitive on this behaviour.

I found in the 5.1.1 section :

The Content-Type field for multipart entities requires one parameter,
"boundary". The boundary delimiter line is then defined as a line
consisting entirely of two hyphen characters ("-", decimal value 45)
followed by the boundary parameter value from the Content-Type header
field, optional linear whitespace, and a terminating CRLF.

So it seems clear that the boundary should be placed last on the line...

[1] Is ASP handling this correctly or not and if so by what spec/rfc?

Seems ok. Been a long time since I tried but in addtion to the spec you
could create an HTML form and use Request.SaveAs or Fiddler to see how the
request is formatted..

[2] Is there a way to get ASP to recognise this input without parsing the
total content stream myself?

It doesn't seem compliant. Anyway if it's not I don't see how you could even
hope so without a convoluted solution (such as transforming the request to
correct it whihc comes basically to parsing it yourself)...

For now it seems to me you have strong arguments to tell the iPhone
developer that the request is not well formed...

 

[Tim]

Hi, Thanks for the input Patrice

I read the 5.1.1 section and to me its just the definition of the actual use
of the boundary item as a section boundaries, as its only the actual section
boundaries that require the -- before them.

It refers to the "boundary parameter value from the Content-Type header
field" which makes it sound like the boundary parameter should be handled in
exactly the same way all other parameters are in which case the semi-colon
should signify the end of that parameter.

I have used Fiddler and several other sources and the boundary is always at
the end - but that appears to be by convention rather than spec. Trust Apple
to do things different - but being inconsistent across devices is even
worse!!

I agree with you on having a "strong argument" - but unfortunately It's not
proving strong enough

Thanks for the answer anyways

 

[Patrice]

This description is for the "content-type field" so it looks quite clear to
me that this is the line that begins with Content-Type: and they tell that
the boundary must be followed by a CRLF (and possibly before optional linear
whitespace).

To me, the actual use is described few lines later :

" The boundary delimiter MUST occur at the beginning of a line, i.e.,
following a CRLF, and the initial CRLF is considered to be attached
to the boundary delimiter line rather than part of the preceding
part."

Also it seems to me charset is not supposed to be here but in another
optional content-type header that is inside the boundaries...

Finally the reality check is that it doesn't work and that it works when
corrected. So clearly the iPhone implementation is different from anything
else that POST to an IIS server even if it is supposed to follow the
standard.

Not sure if it works with the later or an older version (as it seems that
their application doesn't handle the post the same way on all iPhones).

Hopefully the iPhone guy will understand (why is this so difficult to change
this, or does he tell that MS should change how IIS handles web requests ?)

You could try also to ask them against which server it works (ASP "Classic",
Apache ?, does it work with some ASP.NET users with this exact request
formatting ?)...