tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Len Popp" <>
Subject Re: Post form with "x-www-form-urlencoded" content type and Coyote Connector
Date Mon, 18 Aug 2008 22:03:01 GMT
No, when a browser sends a POST request the request params are *not*
sent as part of the request URI. They are sent in the body of the
request. With Content-Type: application/x-www-form-urlencoded the
request body looks like this:


You can use a browser plugin such as LiveHTTPHeaders or ieHTTPHeaders
to look at the contents of the request and make sure the parameters
are in the request body.

You are supposed to be able to read the request body using
request.getInputStream(). However if you call request.getParameter()
first it reads the request body so getInputStream() won't work
afterwards. I don't know if there are any other issues with

On Mon, Aug 18, 2008 at 17:02, André Warnier <> wrote:
> 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 "idempotent".
> - 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.
> André
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:
View raw message