How is a multipart http request received/consumed by a server.

[chaitanya karthikk]

Hi all,

I would like to know the details about how a server handles a multipart request. I know that a webserver comprises of a HTTP adapter(which is responsible for receiving http requests and sending http responses) and a container(which is responsible for handling dynamic requests).

So, when a client sends a request, the HTTP adapter receives it. Then transfers the request to the container if the http adapter cannot handle it(jsps, servlets for example).

Suppose, a client sends a multipart request which has an avi file of size upto 100mb. For example, lets assume that the client takes 5 minutes to upload the file.

Lets also assume that my application is only interested in flv files. Is there any way to stop/terminate the multipart request before the file is transferred to the server? So that the client's time will not be wasted?

I think that the HTTP adapter will transfer the request to the container only after receiving the entire request, i.e. the servlet will be called only after the file is transferred to the server from client. Is it right?

If its right then there is no easy way to terminate the multipart request unless the entire file is transferred to the server. Is this right?

Thank you all.

[Tim Holloway]

I'm not sure what you mean by an "http adapter". A server such as Tomcat receives all incoming traffic the same, but routes it to different subsystems and applications, depending on the URL. What you're referring to as the "http adapter" sounds a lot like the Default Servlet, which is where stuff goes if the appserver cannot determine any more suitable place to send it.

A MIME Multipart POST request consists of a single data stream posted to one of the application server's HTTP or HTTPS receiving ports. There are no "files" as such. When you "submit a file" what you are actually doing is creating a POST request where the file's data is copied into the request stream.

Within that stream you have the usual suspects (headers and so forth) plus one or more sections that are bracketed by (hopefully) unique text streams. If the contents of that particular section are binary, they are converted to text using a modulo-64 scheme that ensures that every binary byte is converted to 2 characters, since HTTP was designed to be bounced between multiple systems as text streams and not all of the original Internet machines spoke ASCII (IBM mainframes, in particular).

The client doesn't have the intelligence to send the parts separately, nor does the server. It's not in the HTTP protocol. The closest approximation would be "chunking", but that's for fragmenting the data stream by byte count, not content. On the server side, the POST pre-processor will recognize the sections and split them out when a MIME-MULTIPART post comes in, but that's independent of the data transport. It can't reach back upstream and force a termination, much less a "skip data" request.

Going back to basics, all HTTP is a request/response cycle with a 1-to-1 request-to-response ratio. So in other words, your POST isn't multiple requests, it's a single request, and it results in a single response - the same reason why a single web request cannot return multiple files going the other direction.