The client in Question is Safari 5.0.4. I doubt is does something wrong.
But you are right, most of these problems derive from the fact the multipart encoded
request
is wrong in some place.
What I've noticed after replacing the server side pieces with the ASL ones,
was that the test cases failed, because it seemed to be using an erroneous request.
Beginning with the missing "boundary" delimiter as part of the content type
header.
AFAIK it's required.
Anyway, this is not abut blaming anyone. I've just wanted to take the shortest path
to desired functionality.
Not sure about the ASL though.
Ike
On Apr 15, 2011, at 2:17 PM, Jonathan Pearlin wrote:
Ike,
One more thing to add: when I wrote the smoke tests for the upload API, I did notice
a similar issue. However, it turned out that I was not creating the multipart POST
correctly (an error in how I was programmatically building the multipart was cauing the
parsing to enter into an infinite loop and run out of memory). However, once I fixed the
test code to produce a valid multipart post, everything was fine. In my normal
development testing, I tested by uploading the Hudson WAR file (which is about 34 MB and
much larger than the one you see the issue with). However, while it is possible that this
issue is due to whatever is submitting the upload request not following the multipart
specification, the code probably does need to be changed to handle multipart requests that
do not contain completely valid data (if we cannot use the Apache library). I would be
curious to see what the POST looks like that is causing the issue (in terms of the
mutlipart boundary, header and payload). It is fairly easy to modify the server code to
dump the incoming POST request to a file to see if it is at all different than what is
expected.
Thanks,
--Jonathan