From: Tim on
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


From: Tim on
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


From: Tim on
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


From: Patrice on
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...

--
Patrice


From: Tim on
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 :)