tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Post form with "x-www-form-urlencoded" content type and Coyote Connector
Date Mon, 18 Aug 2008 21:02:18 GMT
deniak wrote:
> Actually, it's a POST request:
> When I receive the request, I want to deal with an input stream.
> David Smith-2 wrote:
>> Forgive me if I'm wrong, but this looks like the browser should send a 
>> GET request.  Why would you expect an input stream?
>> --David
I believe there is some confusion here.
This is what I understand from the specs (the various relevant RFCs) :

1) the HTTP protocol supports several types of requests (verbs) from the 
client to the server.
(This is what you specify in the "method" attribute of the <form> tag, 
and by default I believe it is GET).

- one type of request is a GET.  This should be used for requests that 
merely *retrieve* information from the server, without changing anything 
on the server.  In other words, several consecutive GETs to the server 
for the same thing should have the same result, and one GET should not 
influence the result of a subsequent GET. That is wat the RFCs call 
- another type of request is a POST. A POST should be used when the 
request may change things on the server.  For example, you would use a 
POST to update a database record, or put some new data or new file onto 
the server, which will result in a subsequent GET or POST to retrieve 
possibly different data from the server.

(In the practice, you can get away with either one.  But that is because 
usually servers are not picky between GETs and POSTs.)

2) separate and distinct from the above, is how your browser and html 
form send the <form> input field values to the server.
- If your <form> specifies an attribute "enctype" of 
"application/x-www-form-urlencoded", then, as the name indicates, the 
form input field values are sent as part of the request URL.
Like "http://myhost/something?field1=value1&field2=value2.."
(and any character in the field values that is not iso-latin-1 should be 
encoded as a "%xx" substitute, and there is no way to specify a 
character set other than the default, and there may be a limit to the 
size of such a URI etc.. etc..)
- if your form specifies an "enctype" of "multipart/form-data", then the 
form field values are not sent as part of the URL.
Instead, the HTTP request to the server now will consist of a "header" 
and a "body".  And the body will consist of a multi-part MIME-like body 
(much like an email), consisting of one part per form parameter.  Each 
of these parts will have in turn a header and a body, the header 
containing header fields such a "Content-type" and "Content-length" 
etc.., and the body being the value of the form input field.
That is much more "powerful", as it allows to send field values which 
are (theoretically) in different character sets, of unlimited size, 
zipped and whatnot. You can even send a whole file as a field, which is 
why the RFC quoted before mentions this specifically.

I further believe that the default, for a browser, if you do not specify 
an explicit "enctype" attribute in the <form> tag, is to send the 
request as "application/x-www-form-urlencoded".
(I would not a-priori discount the possibility that some sub-version of 
Internet Explorer would do otherwise).

Now on the server side, something receives the HTTP request and decodes it.
Either this receiving side is smart enough to decode the request 
parameters (the form field values) and provide them to the application 
with one single interface, no matter how the request has been sent (as 
parts of the URL or as parts of the request body, or even both), or it 
is not.

If it is, then from within the application, you can issue calls like 
"var1 = HttpRequest.getParameter("field1")", and this will return the 
value of the form field, whether it was sent as part of the URL or as 
part of the request body. With luck, it may even be smart enough to 
handle character encoding matters too.

If it is not, then it falls to the application to check the request and 
determine if it should parse the request URL to get at the parameters, 
or read and parse the body (with something like an InputStream and some 
MIME-decoding logic) to get at the parameter values.

I honestly don't know how smart Tomcat is in that respect, but I guess 
it is smart enough to provide a smooth generic interface.
(If you are using Apache and perl, that's what the CGI module does : no 
matter how the request is sent, you can get a form field value using the 
param("name") function. Your mileage may vary.)

But anyway, this is I believe the reason why, if the form specifies an 
'enctype="application/x-www-form-urlencoded"' attribute, you would not 
find any request body to read with an InputStream.
And it probably has nothing to do with the Coyote connector.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message