You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by deniak <de...@gmail.com> on 2008/08/18 19:07:09 UTC
Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Hi all,
Has anyone ever used a form with "x-www-form-urlencoded" Content-Type to a
web application running on tomcat?
I don't know why but when I use that kind of Content-Type, my inputstream is
empty.
There's no problem if I use another Content-Type.
It seems there's a problem with coyote connector but I can't figure out what
it is...
Any clue?
--
View this message in context: http://www.nabble.com/Post-form-with-%22x-www-form-urlencoded%22-content-type-and-Coyote-Connector-tp19035430p19035430.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post form with "x-www-form-urlencoded" content type and Coyote Connector
Posted by Youssef Mohammed <yo...@gmail.com>.
It could be because TC reads and parses the the input stream for you, so you
can get them though request.getParameter (and other methods).
If the request content type is something different (e.g. xml/text ), you
would have the input stream then and read it the way you want.
This is just my guess, sorry if this didn't turn to be right.
On Mon, Aug 18, 2008 at 8:07 PM, deniak <de...@gmail.com> wrote:
>
> Hi all,
>
> Has anyone ever used a form with "x-www-form-urlencoded" Content-Type to a
> web application running on tomcat?
> I don't know why but when I use that kind of Content-Type, my inputstream
> is
> empty.
> There's no problem if I use another Content-Type.
> It seems there's a problem with coyote connector but I can't figure out
> what
> it is...
>
> Any clue?
> --
> View this message in context:
> http://www.nabble.com/Post-form-with-%22x-www-form-urlencoded%22-content-type-and-Coyote-Connector-tp19035430p19035430.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Regards, Youssef
Re: Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Posted by Mark Thomas <ma...@apache.org>.
André Warnier wrote:
> Len Popp wrote:
>> 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:
>>
>> param1=a¶m2=b
>>
>> 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.
>>
> I did, and you're right, I stand corrected.
> It is clearly explained here :
> http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.3
> Step four: Submit the encoded form data set
>
> and it becomes a lot clearer once you know what it means of course.
> ;-)
>
> So, a follow-up question :
> if you do a request.getInputStream(), do you get the body "raw" ?
> (meaning you them have to do your own decoding of the parameters ?)
Yes. Unless you (or a filter, or a valve - the request dumper valve is
often a culprit here) call getParameter() first.
Mark
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Posted by André Warnier <aw...@ice-sa.com>.
Len Popp wrote:
> 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:
>
> param1=a¶m2=b
>
> 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.
>
I did, and you're right, I stand corrected.
It is clearly explained here :
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.3
Step four: Submit the encoded form data set
and it becomes a lot clearer once you know what it means of course.
;-)
So, a follow-up question :
if you do a request.getInputStream(), do you get the body "raw" ?
(meaning you them have to do your own decoding of the parameters ?)
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post form with "x-www-form-urlencoded" content type and Coyote Connector
Posted by Len Popp <le...@gmail.com>.
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:
param1=a¶m2=b
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
getInputStream().
--
Len
On Mon, Aug 18, 2008 at 17:02, André Warnier <aw...@ice-sa.com> wrote:
> deniak wrote:
>>
>> Actually, it's a POST request:
>> http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
>>
>> 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: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Posted by André Warnier <aw...@ice-sa.com>.
deniak wrote:
> Actually, it's a POST request:
> http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
>
> 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: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Posted by deniak <de...@gmail.com>.
Actually, it's a POST request:
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
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
>
--
View this message in context: http://www.nabble.com/Post-form-with-%22x-www-form-urlencoded%22-content-type-and-Coyote-Connector-tp19035430p19038738.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Post form with "x-www-form-urlencoded" content type and Coyote
Connector
Posted by David Smith <dn...@cornell.edu>.
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
deniak wrote:
> Hi all,
>
> Has anyone ever used a form with "x-www-form-urlencoded" Content-Type to a
> web application running on tomcat?
> I don't know why but when I use that kind of Content-Type, my inputstream is
> empty.
> There's no problem if I use another Content-Type.
> It seems there's a problem with coyote connector but I can't figure out what
> it is...
>
> Any clue?
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org