Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 6/19/2009 4:10 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Reading POSTed data The servlet spec is very clear about when the request is consumed to fulfill a getParameter call and when the request is specifically /not/ consumed. What I find problematic is that the spec gives no hint about how to process POST data that is not parameterized. Lack of mentioning any alternative gives the impression that parameterization is the only way of handling it, whereas real-world practice is quite different. You're right: the spec does not specifically mention how to read POST data that isn't handled by the container. On the other hand, should it? I don't believe so: the spec tells you that the data will still be available in the request input stream/reader and that the application can do what it wishes. What did you expect it to say? Some best practices or suggestions perhaps? That kind of thing doesn't really appear anywhere else in the spec. Multipart is a good example: multipart requests are not mentioned a single time in the spec, yet those types of requests are used every day by lots of people without interference from containers. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko/3FUACgkQ9CaO5/Lv0PBklgCfWEYtqVvompdwOtTILsMHQyhB GPIAn0h1+KZKNdNbnUpHgOFQKu0ugSL8 =kxkC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/20/2009 7:59 AM, André Warnier wrote: Or as multipart/form-data... Now this raises an additional nitpicking question : It has been mentioned before, that Tomcat provides no standard mechanism to read POST parameters that have been sent that way. But, the servlet spec 3.0, at the end of section 3.1, says : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). Now, considering that, for a html form, it is entirely valid to send form parameters using the multipart/form-data encoding, and considering the above paragraph, where does that leave us ? The spec still only mentions application/x-www-form-urlencoded, so multipart/form-data parsing is up to the application (or, more practically, a library used by the application). It should mean that the getParameterMap() method, for instance, has at least to peek at the body, determine if it /could/ contain parameters, and if yes parse it to extract them. True. If it does, then Tomcat /does/ contain code that can parse a multipart/form-data body. No. Part of the peek process is to check the content-type. A content-type of multipart/form-data is ignored. If it doesn't, then Tomcat does not respect the servlet spec. No, it's adhering to the spec. You're confusing POST data (in general) with POST data identified as parsable by the servlet spec in section 3.1.1 (of 2.5... not sure about 3.0). Tomcat will simply ignore multipart/form-data requests when it comes to parameter parsing. Other libraries can be rigged to provide parameter data from both sources (GET and multipart POST). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko/3ZsACgkQ9CaO5/Lv0PDyiACgknhVNvhfRj2aUvPLct31BlW6 r4kAn0QKoKlmm4ouQ13Fy9Sq1yhdz7Am =VIgv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Caldarale, Charles R wrote: From: Alan Chaney [mailto:a...@compulsivecreative.com] Subject: Re: Reading POSTed data I don't want to appear picky, but that doesn't actually seem that problematic. If you don't set the content type as application/x-ww-form-urlencoded then you should be able to read it via the input stream Agreed; I must have missed that sentence when I originally went exploring when the question came up. Or as multipart/form-data... Now this raises an additional nitpicking question : It has been mentioned before, that Tomcat provides no standard mechanism to read POST parameters that have been sent that way. But, the servlet spec 3.0, at the end of section 3.1, says : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). Now, considering that, for a html form, it is entirely valid to send form parameters using the multipart/form-data encoding, and considering the above paragraph, where does that leave us ? It should mean that the getParameterMap() method, for instance, has at least to peek at the body, determine if it /could/ contain parameters, and if yes parse it to extract them. If it does, then Tomcat /does/ contain code that can parse a multipart/form-data body. If it doesn't, then Tomcat does not respect the servlet spec. Or ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
André Warnier wrote: Caldarale, Charles R wrote: From: Alan Chaney [mailto:a...@compulsivecreative.com] Subject: Re: Reading POSTed data I don't want to appear picky, but that doesn't actually seem that problematic. If you don't set the content type as application/x-ww-form-urlencoded then you should be able to read it via the input stream Agreed; I must have missed that sentence when I originally went exploring when the question came up. Or as multipart/form-data... Now this raises an additional nitpicking question : It has been mentioned before, that Tomcat provides no standard mechanism to read POST parameters that have been sent that way. But, the servlet spec 3.0, at the end of section 3.1, says : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). Now, considering that, for a html form, it is entirely valid to send form parameters using the multipart/form-data encoding, and considering the above paragraph, where does that leave us ? It should mean that the getParameterMap() method, for instance, has at least to peek at the body, determine if it /could/ contain parameters, and if yes parse it to extract them. If it does, then Tomcat /does/ contain code that can parse a multipart/form-data body. If it doesn't, then Tomcat does not respect the servlet spec. Or ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Ok ... 1. servlet spec 3.0 is not finalized yet and someone might want to bring this up to them before it goes final (looks like that could be soon) 2. tomcat only has to look at the content type header of the post to see what kind of data is in the post. It doesn't have to peak at the post body. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, As fun as beating a dead horse is... On 6/17/2009 6:28 PM, André Warnier wrote: My point (awaiting a more expert opinion still), is that I believe that the way the servlet spec is written, you may very well get away with it under one servlet container, but not under another. The servlet spec is very clear about when the request is consumed to fulfill a getParameter call and when the request is specifically /not/ consumed. As an aside : in your case, there is also not much stopping you from sending your XML body in a way guaranteed to work in all cases. You could send it as name= all your XML, properly URL-encoded .. If you have huge documents, this is a bad idea, because it requires that the entire XML document be loaded into a single string in memory in order to be manipulated. If you have a multi-megabyte document coming in, reading it into a single String is a sure way to make your application unstable. A better way is to stream the XML document through a SAX parser, doing whatever processing is necessary. This is /not possible/ if you force the container to load the entire string via getParameter. Then it would work also with getParameters(). Note that Kyle was never trying to use getParameter. He was always trying to read the body himself. He was just doing it wrong :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko77tEACgkQ9CaO5/Lv0PDbEwCgp0KagaG8ravHan0/oFISPQp1 DO4AoL215X+2bSaa+VfIHeE5Wx1HDoeu =WCaV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/17/2009 6:42 PM, André Warnier wrote: .. just don't do any getParameter() with your stuff. That, I believe, /may/ still get you in trouble. But I'm sure by now Chuck is already checking the Tomcat code of getParameter(), to see if that's the case. Still no problem: the spec says that if the Content-Type is application/xml (or whatever /isn't/ application/x-www-form-urlencoded), the request body will be ignored and available for the servlet to read. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko777gACgkQ9CaO5/Lv0PCtCACfXCaHl9snXTYSx2D0cCojEfMK bN4AnApmbvvRicpbrt3+FB8Mmde6i0YE =v0RX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Reading POSTed data The servlet spec is very clear about when the request is consumed to fulfill a getParameter call and when the request is specifically /not/ consumed. What I find problematic is that the spec gives no hint about how to process POST data that is not parameterized. Lack of mentioning any alternative gives the impression that parameterization is the only way of handling it, whereas real-world practice is quite different. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Reading POSTed data
Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Reading POSTed data The servlet spec is very clear about when the request is consumed to fulfill a getParameter call and when the request is specifically /not/ consumed. What I find problematic is that the spec gives no hint about how to process POST data that is not parameterized. Lack of mentioning any alternative gives the impression that parameterization is the only way of handling it, whereas real-world practice is quite different. - Chuck I have an application which extensively uses message data in POST requests so I was a bit concerned by your comment above. However, P36 of my copy of the 2.4 servlet spec (sec SRV 4.1.1) says If [the POST Form data conditions] are not met and the post form data is not included in the parameter set, the post data must still be available to the servet via the request object's input stream. I don't want to appear picky, but that doesn't actually seem that problematic. If you don't set the content type as application/x-ww-form-urlencoded then you should be able to read it via the input stream Regards Alan Chaney THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. !DSPAM:4a3bf2e676342136417547! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
From: Alan Chaney [mailto:a...@compulsivecreative.com] Subject: Re: Reading POSTed data I don't want to appear picky, but that doesn't actually seem that problematic. If you don't set the content type as application/x-ww-form-urlencoded then you should be able to read it via the input stream Agreed; I must have missed that sentence when I originally went exploring when the question came up. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Reading POSTed data
Kyle Brantley (and many others) wrote: ... Sorry to interrupt, but actually guys I believe that the problem is due to the way the data is POSTed, which in this case is - I believe - invalid. See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 The data of a POST can be sent according to one of two encodings : application/x-www-form-urlencoded OR multipart/form-data This data is neither. The way the data is sent in this case may be appropriate for a PUT, but not for a POST. This may be why the usual servlet methods are getting confused. To Kyle : Create a simple form .. in html, with two text input fields (and a submit button). To the form tag, add an explicit enctype attribute : form action=here_your_webapp_URL enctype=application/x-www-form-urlencoded and submit the form to your webapp. See what goes out with wireshark. Then change the enctype in the form to multipart/form-data, submit again, and look in wireshark. These are the two ways you can submit data. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
André Warnier wrote: Addendum : from Servlet Spec 2.5 : SRV.3.1.1 When Parameters Are Available The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. If the conditions are not met and the post form data is not included in the parameter set, the post data must still be available to the servlet via the request object’s input stream. If the conditions are met, post form data will no longer be available for reading directly from the request object’s input stream. Just thought I'd save Chuck a cut-and-paste.. Now, to be totally forthcoming, I must say that I did not find some definite clearcut spec anywhere (like RFC2616 or the servlet spec) that POST data *must* be one of the two encodings mentioned earlier, exclusive of all others. Interestingly, the servlet spec's wording even sounds like it would leave open the encoding, when it is /not/ application/x-www-form-urlencoded. But it does talk about POST form data and parameter set, which in my view explicitly refers to this : http://www.w3.org/TR/html401/interact/forms.html#form-data-set This last in turn clearly specifies that POST data should be at least in pairs of parameter name / parameter value. Which this XML data anyway is not. CQFD. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Change your loop to be:
int i;
while ((i=in.read())) {
out.write(i);
}
available() - Returns the number of bytes that can be read (or skipped
over) from this input stream without blocking by the next caller of a
method for this input stream. So its not an accurate gauge of how much
content is available from the client.
-Tim
Kyle Brantley wrote:
I'm honestly not sure (being an entire day into tomcat servlets), but
I don't believe so.
Full code:
public class Frontend extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
InputStream in = request.getInputStream();
response.setContentType(text/xml);
response.setCharacterEncoding(UTF-8);
response.setStatus(HttpServletResponse.SC_OK);
while (in.available() 0)
out.write(in.read());
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kyle, On 6/16/2009 11:24 PM, Kyle Brantley wrote: The getParameter() calls are going to be of little to no value for me. The data isn't in a form where those calls would recognize them. Unless I'm missing something very obvious...? No, if you're sending a whole document, then the getParameter calls will not be useful to you. But thanks for the bit about the possible interference in method calls. getParameter and friends will only read the request body if: 1. The request is HTTP or HTTPS (duh) 2. The request method is POST 3. The Content-Type is application/x-www-form-urlencoded Since your Content-Type is text/xml, the request body should be available via request.getReader (preferred for text formats) or request.getInputStream. Note that InputStream.available() returning 0 just means that the next call to InputStream.read(...) will block before returning data. It doesn't mean that there's no data that could be read. When InputStream.read returns -1, that's when you know the stream is out of data. I disagree with Chuck's assertion that POST is inappropriate unless form data is being sent. The only really appropriate HTTP methods for sending lots of data are POST and PUT. PUT is (IMO) not appropriate because the client is expected to provide the URI where the resource should be available later. HTTP section 9.6 says it plainly: The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. [...] In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. I like POST for your requirements. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5Jr0ACgkQ9CaO5/Lv0PB33gCcDcbGVQWRJFKa0sYWOyUOhJr1 ViIAn35KtGzaBJmG0dz8KaWhe6jtZimj =JEyB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/17/2009 4:06 AM, André Warnier wrote: Sorry to interrupt, but actually guys I believe that the problem is due to the way the data is POSTed, which in this case is - I believe - invalid. See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 Note that this is an HTML thing, not an HTTP thing. HTML forms may only be sent using two distinct Content-Types, but HTTP POST can do anything it wants. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5KTkACgkQ9CaO5/Lv0PCtRQCfc2n/B5xeG9NSnMgWou0v3REI taoAnA7RpmsmbzTGdiTCksI1+W2mmvFE =Gf83 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Tim Funk wrote: available() - Returns the number of bytes that can be read (or skipped over) from this input stream without blocking by the next caller of a method for this input stream. So its not an accurate gauge of how much content is available from the client. That explains that quite nicely. The problem wasn't my InputStream, but rather just my use of .available(). I tweaked your loop a bit, but it works - thanks. Christopher: Concerning the getParameter*() calls and info, yeah, I knew that much. I had only gone poking with them as a result of desperation. I too like POST for my requirements. :) Thanks for the help, all. It's working. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/17/2009 4:06 AM, André Warnier wrote: Sorry to interrupt, but actually guys I believe that the problem is due to the way the data is POSTed, which in this case is - I believe - invalid. See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 Note that this is an HTML thing, not an HTTP thing. HTML forms may only be sent using two distinct Content-Types, but HTTP POST can do anything it wants. In a restricted sense, I agree. But then, the servlet spec (2.5) explicitly talks about form data 2 times, for post data 1 single time. If the conditions are not met and the *post form data* is not included in the parameter set, the *post data* must still be available to the servlet via the request object’s input stream. If the conditions are met, *post form data* will no longer be available for reading directly from the request object’s input stream. Mmmm. What does the 3.0 Servlet Spec say ? Well, in section 3.1.1, it now only mentions form data, twice. My main objection though, derives from this previous paragraph, at the end of section 3.1 : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). So, what in case there /are/ parameters in the URL ? How would the servlet container /combine/ these with a body made of XML or whatever else raw data ? Maybe I am interpreting this one step too far, but it seems to me from all this, that the designers of the Servlet Spec at least, were only planning for form data, in pairs of parameter=value, and not for one big data blob (without parameter name) in the body. To me thus, the correct way - and the only way a browser would do it - to POST this data, would be in the form of a multipart/form-data body, itself composed of a MIME header and a body that would be the XML blob. Basically, to me the whole point is that that HTTP server has to be prepared to receive data in some predictable way. Out of the blue, this webapp has no way to know that, for this request that comes in as a POST, getParameters() would crash, because it is trying to get parameter=value things where there are none. That seems wrong. Any further expert comments here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Reading POSTed data Maybe I am interpreting this one step too far, but it seems to me from all this, that the designers of the Servlet Spec at least, were only planning for form data, in pairs of parameter=value, and not for one big data blob (without parameter name) in the body. That was my interpretation as well; the intent appears to be to support only a parameter=value type of POST body, even if there's only one parameter and the length of the value is huge. Anybody here on the committee? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Reading POSTed data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/17/2009 4:58 PM, André Warnier wrote: Christopher Schultz wrote: Note that [restricted content-type] is an HTML thing, not an HTTP thing. HTML forms may only be sent using two distinct Content-Types, but HTTP POST can do anything it wants. In a restricted sense, I agree. But then, the servlet spec (2.5) explicitly talks about form data 2 times, for post data 1 single time. If the conditions are not met and the *post form data* is not included in the parameter set, the *post data* must still be available to the servlet via the request object’s input stream. If the conditions are met, *post form data* will no longer be available for reading directly from the request object’s input stream. Right: this just says that when (properly-advertised) form data is present, it is available via the getParameter family of functions. Mmmm. What does the 3.0 Servlet Spec say ? Well, in section 3.1.1, it now only mentions form data, twice. My main objection though, derives from this previous paragraph, at the end of section 3.1 : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). So, what in case there /are/ parameters in the URL ? How would the servlet container /combine/ these with a body made of XML or whatever else raw data ? It can't, nor should it. If the POST data is not properly-formatted form data, then it's left up to the servlet to decide what to do with it. Maybe I am interpreting this one step too far, but it seems to me from all this, that the designers of the Servlet Spec at least, were only planning for form data, in pairs of parameter=value, and not for one big data blob (without parameter name) in the body. Only form data is supported by the servlet API directly (via getParameter)... other types of data are supported indirectly through getInputStream/getReader. To me thus, the correct way - and the only way a browser would do it - to POST this data, would be in the form of a multipart/form-data body, itself composed of a MIME header and a body that would be the XML blob. Note that multipart/form-data is not supported by the servlet API directly, either. If you want to read multipart/form-data, you need an 3rd-party library (or 1st party... if you feel like writing your own). Basically, to me the whole point is that that HTTP server has to be prepared to receive data in some predictable way. Out of the blue, this webapp has no way to know that, for this request that comes in as a POST, getParameters() would crash, because it is trying to get parameter=value things where there are none. That seems wrong. getParameter, when called in the presence of POST data that is not formatted according to the spec's guidelines, does not consume any part of the request body. The servlet is free to read the data itself. No crashing is necessary. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAko5YGkACgkQ9CaO5/Lv0PBPygCfcBHwGH0O4z7ahSpkALGlcW3p 5PoAn2Xndch9aVPzUBM/xd0AV5sXDhBg =4bPs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
André Warnier wrote:
To me thus, the correct way - and the only way a browser would do it
- to POST this data, would be in the form of a multipart/form-data
body, itself composed of a MIME header and a body that would be the
XML blob.
If I may:
function loadXMLDoc(xmlRequest) {
var xmlDoc;
xmlDoc = new window.XMLHttpRequest();
xmlDoc.open(POST, parent.serverURL, false);
xmlDoc.setRequestHeader(Content-type, text/xml);
xmlDoc.setRequestHeader(Content-length,
xmlRequest.length);
xmlDoc.setRequestHeader(Connection, close);
xmlDoc.send(xmlRequest);
return xmlDoc.responseXML;
}
(Yes, I know I'm doing doing the proper HTTP status return checks. This
is very rough code at the moment.)
I went with this for two reasons: one, it is absurdly simple and two,
there is no required encoding. If I want to send a blob of data, then
I'm going to send a blob of data. I saw a really simple, easy way out of
encoding (sometimes /very/) long strings into the proper urlencoded
form. I pass in an XML string, I get an XML string back - no extra
effort involved. Granted, the getParameter*() methods are there for a
reason. I just chose not to use them.
My point, is that it is entirely possible for a browser to POST data to
a resource without sending it as multipart/form-data or
application/x-www-form-urlencoded.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
André Warnier wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/17/2009 4:06 AM, André Warnier wrote: Sorry to interrupt, but actually guys I believe that the problem is due to the way the data is POSTed, which in this case is - I believe - invalid. See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 Note that this is an HTML thing, not an HTTP thing. HTML forms may only be sent using two distinct Content-Types, but HTTP POST can do anything it wants. In a restricted sense, I agree. But then, the servlet spec (2.5) explicitly talks about form data 2 times, for post data 1 single time. If the conditions are not met and the *post form data* is not included in the parameter set, the *post data* must still be available to the servlet via the request object’s input stream. If the conditions are met, *post form data* will no longer be available for reading directly from the request object’s input stream. Mmmm. What does the 3.0 Servlet Spec say ? Well, in section 3.1.1, it now only mentions form data, twice. My main objection though, derives from this previous paragraph, at the end of section 3.1 : Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbyea= world, the resulting parameter set would be ordered a=(hello, goodbye, world). So, what in case there /are/ parameters in the URL ? How would the servlet container /combine/ these with a body made of XML or whatever else raw data ? Maybe I am interpreting this one step too far, but it seems to me from all this, that the designers of the Servlet Spec at least, were only planning for form data, in pairs of parameter=value, and not for one big data blob (without parameter name) in the body. To me thus, the correct way - and the only way a browser would do it - to POST this data, would be in the form of a multipart/form-data body, itself composed of a MIME header and a body that would be the XML blob. Basically, to me the whole point is that that HTTP server has to be prepared to receive data in some predictable way. Out of the blue, this webapp has no way to know that, for this request that comes in as a POST, getParameters() would crash, because it is trying to get parameter=value things where there are none. That seems wrong. Any further expert comments here ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Having had to recently do some SOAP work, it looks to me that is at least partially what the OP was trying to begin with. SOAP performs a POST with XML as the body of the request. It's not URI encoded parameters or multipart data like the HTML Form posts, but a standard POST operation with an xml body. This is legitimate stuff to do and I would consider the spec broken if it didn't support it. Just my two cents. --David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Kyle Brantley wrote: ... My point, is that it is entirely possible for a browser to POST data to a resource without sending it as multipart/form-data or application/x-www-form-urlencoded. Hey! that is cheating. You never mentioned Javascript before. ;-) But true. I wasn't thinking of XMLHttpRequest (which is becoming entirely misnamed these days). You /can/ POST any body which strikes your fancy. And you are also right when you mention that assembling a real multipart/form-data body may be a p. in the a. The real question however is whether you /should/. (In the sense that you /can/ also do a GET or POST with an unparseable query string, but it would not get you far). My point (awaiting a more expert opinion still), is that I believe that the way the servlet spec is written, you may very well get away with it under one servlet container, but not under another. Now whether this is a concern in your particular circumstances, is for you to know. I would gladly read the opinion of one of the designers though. As an aside : in your case, there is also not much stopping you from sending your XML body in a way guaranteed to work in all cases. You could send it as name= all your XML, properly URL-encoded .. Then it would work also with getParameters(). Unless it is really long of course; I would not recommend this with a file. But in that case, there is this : http://commons.apache.org/fileupload/using.html which also allows you to handle multipart/form-data containing blobs and simple form parameters, together in one POST. (Mentioning it because I have often found that what is at the beginning a simple case where all we need to upload, ever, is a single blob, turns out in the end to be ..but we'd also like to send some additional meta-data describing the blop). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
David Smith wrote: Having had to recently do some SOAP work, it looks to me that is at least partially what the OP was trying to begin with. SOAP performs a POST with XML as the body of the request. It's not URI encoded parameters or multipart data like the HTML Form posts, but a standard POST operation with an xml body. This is legitimate stuff to do and I would consider the spec broken if it didn't support it. Just my two cents. I (relunctantly) believe you're right, and that I was being unnecessarily pernickety. At least according to this : http://www.w3schools.com/SOAP/soap_example.asp OP, all is forgiven. And David, you get your two cents back. ;-) .. just don't do any getParameter() with your stuff. That, I believe, /may/ still get you in trouble. But I'm sure by now Chuck is already checking the Tomcat code of getParameter(), to see if that's the case. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
André Warnier wrote: Kyle Brantley wrote: ... My point, is that it is entirely possible for a browser to POST data to a resource without sending it as multipart/form-data or application/x-www-form-urlencoded. Hey! that is cheating. You never mentioned Javascript before. ;-) But true. I wasn't thinking of XMLHttpRequest (which is becoming entirely misnamed these days). You /can/ POST any body which strikes your fancy. And you are also right when you mention that assembling a real multipart/form-data body may be a p. in the a. Which is really the only reason that matters as to why I wanted to do it. I don't want to encode/decode to send to the server, and then do the same to send to the client. It's a very simple solution. The real question however is whether you /should/. Definitely. Granted on every count. My point (awaiting a more expert opinion still), is that I believe that the way the servlet spec is written, you may very well get away with it under one servlet container, but not under another. Now whether this is a concern in your particular circumstances, is for you to know. *nod* Probably will only ever be using tomcat. Unless someone suggests something else, but I don't think that would be the case... /here/. :) As an aside : in your case, there is also not much stopping you from sending your XML body in a way guaranteed to work in all cases. You could send it as name= all your XML, properly URL-encoded .. Then it would work also with getParameters(). And you know, I really debated that - but for absolutely no reason at all, I really wanted to see if I could accomplish it without. That, and I wasn't sure if I would need to tack on extra encoding - the XML in question has quite a few element attributes, all with their own var=whatever pairs. I wasn't positive how getParameter*() would parse that, and if I would/wouldn't need to add extra encoding. As you laid out right there, I would need to URL encode the data, and the reality is I just don't care that much (when presented with another solution that works with arguably less effort). The client is straight javascript, and while I'm not the one doing the client (not my problem), it would just be added effort for little to no gain. Unless it is really long of course; I would not recommend this with a file. But in that case, there is this : http://commons.apache.org/fileupload/using.html which also allows you to handle multipart/form-data containing blobs and simple form parameters, together in one POST. (Mentioning it because I have often found that what is at the beginning a simple case where all we need to upload, ever, is a single blob, turns out in the end to be ..but we'd also like to send some additional meta-data describing the blop). Right. I doubt we'll ever have a need for that, but it would also be an option. I am curious just how the expert opinion turns out, though. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
Kyle- i would like to hear some more on how to represent blob with title or content-type metadata an example would be axis2 1.4 HexBinary or Base64Binary (BLOBS) accompanied by a String title such as what is represented by this xmime.xsd xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:xmime=http://www.w3.org/2005/05/xmlmime; targetNamespace=http://www.w3.org/2005/05/xmlmime; xs:attribute name=contentType xs:simpleType xs:restriction base=xs:string xs:minLength value=3 / /xs:restriction /xs:simpleType /xs:attribute xs:attribute name=expectedContentTypes type=xs:string / xs:complexType name=base64Binary xs:simpleContent xs:extension base=xs:base64Binary xs:attribute ref=xmime:contentType / /xs:extension /xs:simpleContent /xs:complexType xs:complexType name=hexBinary xs:simpleContent xs:extension base=xs:hexBinary xs:attribute ref=xmime:contentType / /xs:extension /xs:simpleContent /xs:complexType /xs:schema ? Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Wed, 17 Jun 2009 16:45:34 -0600 From: k...@averageurl.com To: users@tomcat.apache.org Subject: Re: Reading POSTed data André Warnier wrote: Kyle Brantley wrote: ... My point, is that it is entirely possible for a browser to POST data to a resource without sending it as multipart/form-data or application/x-www-form-urlencoded. Hey! that is cheating. You never mentioned Javascript before. ;-) But true. I wasn't thinking of XMLHttpRequest (which is becoming entirely misnamed these days). You /can/ POST any body which strikes your fancy. And you are also right when you mention that assembling a real multipart/form-data body may be a p. in the a. Which is really the only reason that matters as to why I wanted to do it. I don't want to encode/decode to send to the server, and then do the same to send to the client. It's a very simple solution. The real question however is whether you /should/. Definitely. Granted on every count. My point (awaiting a more expert opinion still), is that I believe that the way the servlet spec is written, you may very well get away with it under one servlet container, but not under another. Now whether this is a concern in your particular circumstances, is for you to know. *nod* Probably will only ever be using tomcat. Unless someone suggests something else, but I don't think that would be the case... /here/. :) As an aside : in your case, there is also not much stopping you from sending your XML body in a way guaranteed to work in all cases. You could send it as name= all your XML, properly URL-encoded .. Then it would work also with getParameters(). And you know, I really debated that - but for absolutely no reason at all, I really wanted to see if I could accomplish it without. That, and I wasn't sure if I would need to tack on extra encoding - the XML in question has quite a few element attributes, all with their own var=whatever pairs. I wasn't positive how getParameter*() would parse that, and if I would/wouldn't need to add extra encoding. As you laid out right there, I would need to URL encode the data, and the reality is I just don't care that much (when presented with another solution that works with arguably less effort). The client is straight javascript, and while I'm not the one doing the client (not my problem), it would just be added effort for little to no gain. Unless it is really long of course; I would not recommend this with a file. But in that case, there is this : http://commons.apache.org/fileupload/using.html which also allows you to handle multipart/form-data containing blobs and simple form parameters, together in one POST. (Mentioning
RE: Reading POSTed data
From: Kyle Brantley [mailto:k...@averageurl.com] Subject: Reading POSTed data I'm trying to read data which is posted directly to the server. I'll assume you have a doPost() method in your servlet. I cannot figure out how to read this posted data from the servlet. Read the servlet spec, not just the javadocs; section 3.1 discusses how POST data should be retrieved (as parameters). Even if you limit yourself to the javadocs, you should have noticed this in ServletRequest.getParameter(): If the parameter data was sent in the request body, such as occurs with an HTTP POST request, then reading the body directly via getInputStream() or getReader() can interfere with the execution of this method. The variations of getParameter(), especially getParameterMap(), can be quite useful. A simple example: http://www.javareference.com/jrexamples/viewexample.jsp?id=101 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
Caldarale, Charles R wrote: From: Kyle Brantley [mailto:k...@averageurl.com] Subject: Reading POSTed data I'm trying to read data which is posted directly to the server. I'll assume you have a doPost() method in your servlet. I do. I cannot figure out how to read this posted data from the servlet. Read the servlet spec, not just the javadocs; section 3.1 discusses how POST data should be retrieved Hey thanks, I will. (as parameters). Even if you limit yourself to the javadocs, you should have noticed this in ServletRequest.getParameter(): If the parameter data was sent in the request body, such as occurs with an HTTP POST request, then reading the body directly via getInputStream() or getReader() can interfere with the execution of this method. The variations of getParameter(), especially getParameterMap(), can be quite useful. A simple example: http://www.javareference.com/jrexamples/viewexample.jsp?id=101 The getParameter() calls are going to be of little to no value for me. The data isn't in a form where those calls would recognize them. Unless I'm missing something very obvious...? But thanks for the bit about the possible interference in method calls. I'll be sure to check that I'm not calling those combinations of methods - I'm decently sure that at least twice I had both in, just to try and get it working. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Reading POSTed data
2009/6/16 Caldarale, Charles R chuck.caldar...@unisys.com: From: Kyle Brantley [mailto:k...@averageurl.com] Subject: Reading POSTed data I cannot figure out how to read this posted data from the servlet. Read the servlet spec, not just the javadocs; section 3.1 discusses how POST data should be retrieved (as parameters). Ah, but section 3.1.1 says that POST data is only available through getParameter if the content type is application/x-www-form-urlencoded. In Kyle's case, the POST request contains XML data that he wants to read and interpret. Is there any other code that calls getParameter or a related method before you call getInputStream? Maybe in a filter? -- Len - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
From: Kyle Brantley [mailto:k...@averageurl.com] Subject: Re: Reading POSTed data The data isn't in a form where those calls would recognize them. To be a proper POST body, it must be. The content should be preceded by something like xml= (without the quotes), and then you would retrieve the content via getParameter(xml). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Reading POSTed data
From: Len Popp [mailto:len.p...@gmail.com] Subject: Re: Reading POSTed data Ah, but section 3.1.1 says that POST data is only available through getParameter if the content type is application/x-www-form-urlencoded. You're right, I missed that. There must be something else getting at the request before the servlet has a chance to read it. Is there any other code that calls getParameter or a related method before you call getInputStream? Maybe in a filter? What about the RequestDumperValve? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: Reading POSTed data
On 06/16/2009 09:36 PM, Caldarale, Charles R wrote:
From: Len Popp [mailto:len.p...@gmail.com]
Subject: Re: Reading POSTed data
Ah, but section 3.1.1 says that POST data is only available through
getParameter if the content type is application/x-www-form-urlencoded.
You're right, I missed that. There must be something else getting at the
request before the servlet has a chance to read it.
Looking at the code now, it doesn't look like it.
Is there any other code that calls getParameter or a related method
before you call getInputStream? Maybe in a filter?
What about the RequestDumperValve?
I'm honestly not sure (being an entire day into tomcat servlets), but I
don't believe so.
Full code:
public class Frontend extends HttpServlet {
public void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
InputStream in = request.getInputStream();
response.setContentType(text/xml);
response.setCharacterEncoding(UTF-8);
response.setStatus(HttpServletResponse.SC_OK);
while (in.available() 0)
out.write(in.read());
}
}
The document that tomcat sends back has the content type set properly,
but a Content-Length of 0.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
