2

I am writing a web application that submits a form (one of its fields is mulitpart/form-data, so obviously POST must be used and not GET, since the files might be really big). One of the fields is kinda transaction/upload_id and the other is obviously the file contents. While uploading, a progress bar must be displayed.

The known fact says that the order of parameters is undefined in general, meaning that any of (file content / upload_id) might come first.

Is there any acceptable / recommended way to cause the browser to send the upload_id before sending the file content?

Is it a considered a correct implementation - to expect the upload_id to come first OR there is a better / most common / more correct way to handle the problem? In that case - it would be fantastic to hear some details.

Update: my server-side language is Java/Servlets 3.0

BreakPhreak
  • 10,940
  • 26
  • 72
  • 108
  • what's your server-side language? – Anurag May 07 '11 at 23:13
  • thanks for asking - just updated the question: my server-side language is Java/Servlets 3.0 – BreakPhreak May 07 '11 at 23:15
  • Tried to think ahead and thought that for a simple case (only one file per session at a time) - the upload_id is unnecessary. The case with several files it looks like they are considered as a big single chunk and should be tracked together, hence upload_id is unnecessary again. Need to think a bit more on that... – BreakPhreak May 07 '11 at 23:19
  • Yep, thought more - the question is valid if there is more then one submission form on a web-page. – BreakPhreak May 07 '11 at 23:32
  • added an answer. If there is more than one form on the page, then only the contents of the *submitted* form will be passed in as multi-part. Regardless, you shouldn't have t worry about the order in which items are sent. Use a high-level tool to do the job, or write one if needed. – Anurag May 07 '11 at 23:47

3 Answers3

1

Well, the better answer (without utilizing filters) would be to publish the upload_id(s) as a part of the URL (after '?'), even when issuing a POST request. In that case, they will be always processed ahead of files' contents.

BreakPhreak
  • 10,940
  • 26
  • 72
  • 108
0

You shouldn't have to worry about the order in which the parameters are sent. If so, then your server-side code is very brittle.

A multi-part request will contain the field name of every form field that is passed in. Use the name to reference that field regardless of the order it was sent in.

If you are parsing the post body by hand, I suggest you look at existing projects like Apache FileUpload which abstract that away.

Anurag
  • 140,337
  • 36
  • 221
  • 257
  • well, I do realize that some tools provide some useful abstraction, this time I am kinda curious how it is implemented - and yes, probably looking into the source is the only way. technically speaking, when form fields are serialized altogether in HTTP response's body - then they will be serialized SEQUENTIALLY - meaning that IF a big file comes first, then it's upload_id will follow only after. That poses some problem and again, I am a bit curious about the technical solution, just to learn from it. – BreakPhreak May 07 '11 at 23:56
0

Using servlets as well, and in my case I wanted to run my CSRF filter in my servlet before I started streaming the file: if the filter failed, I can kill the request before I've uploaded my 20gb video file, as opposed to the default PHP implementation where the server only hits your script AFTER its parsed the entire request.

Its been a bit of a hack on my part, but in the couple of cases I've had to do this I've cheated and put the non-file request parameters into the URL and in every case (using pretty much every browser I've tested with) an Iterator over the request parameters on the server (I'm using commons fileupload in streaming mode) has received the non-file request parameters first before the file data was received. Somewhat fragile, but not unworkable.

I'm assuming that if you order your request parameters with the file <input> as the last item you'll get the same behavior.

Femi
  • 64,273
  • 8
  • 118
  • 148