aspose file tools*
The moose likes Tomcat and the fly likes Can you change an incoming header pre servlet? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Can you change an incoming header pre servlet?" Watch "Can you change an incoming header pre servlet?" New topic
Author

Can you change an incoming header pre servlet?

S Stevens
Greenhorn

Joined: Jul 05, 2012
Posts: 2
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.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39547
    
  27
Using a servlet filter you could wrap the request in the type of request that your other infrastructure understands.


Ping & DNS - updated with new look and Ping home screen widget
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60053
    
  65

So they are posting form data but saying it's XML? Can you not get them to fix that?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12678
    
    5
Tomcat doesn't automatically parse and find parameters in the request bodywith this type set


Really? Where is this documented?

I was under the impression that a call to request.getParameter( "paramname" ) would always cause tomcat to attempt to parse the body.

Bill

Java Resources at www.wbrogden.com
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60053
    
  65

William Brogden wrote:I was under the impression that a call to request.getParameter( "paramname" ) would always cause tomcat to attempt to parse the body.

No, for POST data it will only do so if the content type is application/x-www-form-urlencoded, which is the default for HTML forms.

Documented in the Servlets 2.4 Spec in section SRV.4.1.1, and Servlets 3.0 Spec in section 3.1.1.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60053
    
  65

P.S. This is the reason for the seemingly weekly posts asking why form parameters are not available when performing files uploads; which require a different request content type.
S Stevens
Greenhorn

Joined: Jul 05, 2012
Posts: 2
Ulf Dittmer wrote:Using a servlet filter you could wrap the request in the type of request that your other infrastructure understands.

I wasn't sure that I could limit a filter it to just one url - I wouldn't want to change every request. I guess that filters is the way to go.

Bear Bibeault wrote:So they are posting form data but saying it's XML? Can you not get them to fix that?

They cant change it as several other companies have had to work around it too and now they don't know the impact of putting it right. It really is just A=1234&B=5678&C=7890 in the body LOL.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15641
    
  15

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.

So

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Can you change an incoming header pre servlet?
 
Similar Threads
Passing header parameters with the request
how to create a link to download pdf file?
setting request header
Need to get the current Instance of one backing bean into another
character encoding problem