I have a servlet that does little but have data POSTed to it. It uses the normal request.getParameter() to pluck out the parameters and values and all is good and has been for some time.
Now my problem. A new supplier has started POSTing data, but one header is "Content-type: text/xml". Tomcat doesn't automatically parse and find parameters in the request bodywith this type set and I've coded up a routine get around this. My question is can the header be selectively changed pre- servlet so that the getParameters will work normally? Some filter in the .conf files?
Any assistance would be appreciated. Thanks.
Joined: Mar 22, 2005
Using a servlet filter you could wrap the request in the type of request that your other infrastructure understands.
S Stevens wrote:
Now my problem. A new supplier has started POSTing data, but one header is "Content-type: text/xml". Tomcat doesn't automatically parse and find parameters in the request bodywith this type set...
No it doesn't. The RFCs in which the Internet is based define the formats for GET and POST requests, including the allowable formats of FORM POST operations. One of the things that is defined in the RFCs is that an HTML FORM sent to the client must have a specific (FORM!) content-type supplied on the outgoing FORM HTML element so that a properly-compliant client will format the return POST (assuming the FORM said "POST" and not "GET") in accordance with the appropriate RFC-defined standard.
There's absolutely nothing wrong with POSTing arbitrary-format data to a webapp. I've done it myself. But don't expect data that's not in the proper encoding scheme to be processed by a decoding mechanism that wasn't designed for it. All you can get from arbitrary-format data is a raw input stream.
BTW, if I'm not mistaken, there are at least TWO different form formats supported by the RFCs - one for "vanilla" form encoding and the other for multipart MIME encoding (which is used for file uploads).
XML isn't an ideal format for HTML FORM data in any event, since it can contain items that are structured in complex ways, but the FORM parsers only support MIME packets and name/value pairs.
And then there's the final nail in the coffin. Not only is there no standard support for arbitrary XML as part of a FORM submit process, but any attempt to force one in using web application logic would be questionable at best, since the request parameters are considered to be a read-only map with read-only keys and values and depending on the brand and version of the J(2)EE server, this property may be strictly enforced.
A) There's no standard for XML "form posting". Hence no container-based parsing of such inputs.
B) Any attempt to jam an XML parser into the process at the application level will have unpredictable results. Even if it works today, you cannot depend on it to work tomorrow. (Note: actually, I believe Tomcat started enforcing read-only parameters somewhere around 5.x, so in the case of Tomcat, it probably won't work today, either).
Having said all that, if you want to - in effect - redefine basic Web protocols, you might be able to construct a Valve that could process the input in question (or questionable input). I don't guarantee that, however, since you're proposing to change some pretty fundamental stuff and that may require customizing Tomcat itself.
One final note, however. If this app was designed to accept HTML FORM POST inputs and someone sends in data that isn't encoded in the manner that was specified, it is not your obligation to modify the server and protocols to accept what is, in effect, hacked data. If they want to send XML, fine, but they need to discuss protocols with the app designers and not just dump down data in arbitrary formats. XML is not a problem. After all, that's what SOAP is. But SOAP also defines the channels, and they don't include tampering with RFC-defined formats.
Customer surveys are for companies who didn't pay proper attention to begin with.