Hi
Isnt it in fact the content type that says what happens, if there is a
stream or not?
The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.
http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type
There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.
- From what I have been reading, it should be safe to assume that if the
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.
If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.
I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>
What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.
Improvement
Closed
Minor
Hi
Isnt it in fact the content type that says what happens, if there is a
stream or not?
The browsers send this mime-type: application/x-www-form-urlencoded for
both POST and GET form submits, unless explicit altered in your html.
This means that the content is available through request.getParameter().
There is no body to stream in.
http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type
There are however also a multipart/form-data system, which is what in
fact is the only supported method in the geoserver now.
You can have url parameters and at the same time stream more data in.
That is the multipart part of this whole deal.
E.g. uploading a file in your html form, or stream bytes directly in
from your code, at the same time as the url contains e.g
http://localhost/geoserver/wms?layers=topp:states.
content type is application/x-www-form-urlencoded, then it does not
matter wether it is post or get. request.getParameter("layers") will
work for both.
If it is not this content type, there are multiple parts to handle.
1 part could be the parameters on the url like on the urlencoded part,
and at the same time there could be a file upload or byte transfer of
some kind.
I wonder if it would be good just to use jakartas commons-fileupload, a
package created for a servlet to easily use a posted multipart/form-data
transmission from any client.
http://jakarta.apache.org/commons/fileupload/
<snip>
FileUpload parses HTTP requests which conform to RFC 1867 ,
"Form-based File Upload in HTML". That is, if an HTTP request is
submitted using the POST method, and with a content type of
"multipart/form-data", then FileUpload can parse that request, and make
the results available in a manner easily used by the caller.
</snip>
What the getReader() accesses is not unlike a fileupload. Maybe even the
exact same.