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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
