• 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

setting request header

 
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The request received by a servlet/jsp, by default, has value "application/x-www-form-urlencoded" for the request header named "content-type". (Pls correct me if I am wrong). The questions are :

1. When would the value of this header be other than the one specified above?
2. Is it possible to change the value of this header somehow?

The thing is that, I am developing a WAP application using JSPs to generate wml content. Following is the default form for post request in a jsp/wml page :

<anchor> Login
<go href="<%=response.encodeURL(contextPath+"/start.jsp")%>" method="post">
<postfield name="mobileNo" value="$mobileNo" />
</go>
</anchor>

Now, in some phones, the request sent by clicking the Login link contains value "application/x-www-form-urlencoded" for the request header "content-type" and in some other phones, the request sent by clicking the Login link contains value "application/x-www-form-urlencoded; charset=106" for header "content-type". And in the later case, the jsp / servlet, receiving the request gets no post parameters (request.getParameter("mobileNo") returns null) - that's probably bcoz Servlet specification says like that ... (am I right?) ... This is the main problem - since no post parameters are available to the called jsp/servlet, no further processing is being done.

So, I was wondering if there is a way through which I can ensure that every request sent contains value "application/x-www-form-urlencoded" for header "content-type"?? If there is one, I think it should solve my problem ...
 
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

Servlet specification says like that ... (am I right?)


No, the parameters will get parsed if they are in the request body, no matter what the content-type value says. The problem must lie elsewhere.
If this was my problem I would dump all the request headers and the InputStream to see what is actually being sent to the servlet.
Bill
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is the dump of the request headers (in case the request.getParameter returns null) :

[test2.jsp]: header name==>host<==, header value==>64.41.252.15<==
[test2.jsp]: header name==>content-type<==, header value==>application/x-www-form-urlencoded; charset=106<==
[test2.jsp]: header name==>accept<==, header value==>text/vnd.wap.wml, text/vnd.wap.wmlscript, image/vnd.wap.wbmp, application/vnd.w
ap.multipart.mixed, image/bmp, image/png, image/gif, image/jpeg, image/vnd.wap.wbmp, application/vnd.wap.wmlc, application/vnd.wap.w
bxml, application/vnd.wap.wmlscriptc, application/xhtml+xml, application/vnd.wap.xhtml+xml, text/html, application/vnd.wap.mms-messa
ge, application/java-archive, application/java, application/vnd.oma.dd+xml, text/css, */*, */*<==
[test2.jsp]: header name==>accept-language<==, header value==>en<==
[test2.jsp]: header name==>accept-charset<==, header value==>us-ascii, iso-8859-1, utf-8, iso-10646-ucs-2<==
[test2.jsp]: header name==>x-wap-profile<==, header value==>http://wap.sonyericsson.com/UAprof/T610R401.xml<==
[test2.jsp]: header name==>user-agent<==, header value==>SonyEricssonT610/R401 Profile/MIDP-1.0 Configuration/CLDC-1.0<==
[test2.jsp]: header name==>bearer-indication<==, header value==>0<==
[test2.jsp]: header name==>accept-application<==, header value==>1, 2<==
[test2.jsp]: header name==>content-length<==, header value==>38<==
[test2.jsp]: header name==>connection<==, header value==>close<==
[test2.jsp]: header name==>x-msisdn<==, header value==>919825079071<==
[test2.jsp]: header name==>via<==, header value==>Jataayu CWS Gateway 3.1.0 at jataayuwap2<==
[test2.jsp]: header name==>x-network-info<==, header value==>UDP, 10.16.26.194<==

And here is the dump of the content read from input stream (entire stringbuffer content) :

[test2.jsp]: Read data from input stream ==>mobileNo=6625016887<==

btw, the reason that I interpreted the content-type thing as stated in my question is because of the following :

Servlet Specification 2.3 - SRV.4.1.1 "When Parameters Are Available" - section states four different conditions that must be met before post form data will be populated to the parameter set, third of which is "The content type is application/x-www-form-urlencoded"

Please correct me if I have interpreted this incorrectly.
 
William Brogden
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
Wow, you are right - I was mistaken. I even found the code in Tomcat 4.1.28 where the check is made. This is in the parseParameters method of HttpRequestBase.java which gets called if getParameters is called.

where contentType has been pulled out of the headers and cleaned up.
If you want to force the value of content-type, a filter would be the way to do it. You can create a custom extension of HttpServletRequestWrapper that has special handling of the getHeader method.
Bill
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am getting a feeling that, if I use a filter to force content type as you said, it would be sort of patch work. I even don't know why servlet specification says that post parameters should not be populated in case the content-type is NOT "application/x-www-form-urlencoded". There must be some reason behind this ...

I haven't worked much with filters, but, if somehow I find a way to do this through filters, then effectively we would force tomcat to parse parameters even if the request originated from the ultimate client has content-type other than "application/x-www-form-urlencoded". Would this be (direct or indirect) violation of servlet spec?

Also can you suggest me some more details for this filtering approach? I know how to write simple filters like set character encoding ... haven't worked with wrappers and all ... or if you can point me to some examples which can be helpful to me ...

Thanks
 
William Brogden
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
This is a nice review article on Filters.
It is true that some sort of filter to force the content-type would be a kludge - but what you would be fixing is the way the phone request headers are treated.
After looking at the servlet code, I don't see why the header

"application/x-www-form-urlencoded; charset=106" for header "content-type"


Is not being recognized - in the Tomcat 4.1.30 code, that value is supposed to be split at the semicolon and trim()ed before being checked. Which servlet engine are you using.
Bill
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Initially I was using Tomcat 4.1.27, but I also tried with Tomcat 4.1.30 today, it returns null with both of these tomcat versions.
 
William Brogden
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
What happens if you iterate through the parameters using getParameterNames() - is any parameter getting parsed at all?
Bill
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nope, I tried that as well, no parameters are getting parsed at all ....
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was wondering how tomcat populates various header values in the request object, coz there is no direct set method that allows to set headers in the request object ...
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried following code with filters, but no luck yet ...

The RequestWrapper code


The Filter code



The web.xml


What I have done wrong in the above code? I am not sure about how this request wrapper class would be used by tomcat ...

With the above code, If I do request.getHeader("content-type") from my JSP page, then it returns me value "application/x-www-form-urlencoded", BUT, the post parameters returned from request.getParameter still returns null, which means, tomcat is not getting the above value of content-type when it is trying to populate request headers.

Also, I have placed a System.out call in the getHeader of my requestwrapper class, which is not being printed when tomcat is populating parameters, which means my wrapper's method is not being called.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I got the URL (that response.encodeURL generates) printed in the system output :

System.out stmt is :
System.out.println("[startn4n.jsp]:encode URL :" + response.encodeURL(contextPath+"/start.jsp") +":" );

Output is :
[startn4n.jsp]:encode URL :/true/start.jsp;jsessionid=6AE362E792368BF9A5A28DDE30F42E5A:

As you can see above, I tried this in context /true

This time, I tried with the following various cases of filter-mapping in web.xml, but no luck yet ...

Option 1:



Option 2:
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
any clues??
 
William Brogden
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
I just realized that you have not said exactly what URL the following code generates:

also you may have the invoker servlet turned on. If that url includes "/servlet/" then processing by the invoker may be messing things up.
Try creating a context separate from the Tomcat /examples.
Bill
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic