• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Can you change an incoming header pre servlet?

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using a servlet filter you could wrap the request in the type of request that your other infrastructure understands.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So they are posting form data but saying it's XML? Can you not get them to fix that?
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic