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=aparam2=b
You
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
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
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
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
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=aparam2=b
You can use a browser plugin
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
