POST-REDIRECT-POST?

response.sendRedirect calls are very commonly used in servlets.  They are used extensively to implement PRG patterns to avoid duplicate form submissions by page refresh and to be more bookmark-friendly.  I have had requirements in my application where I need to redirect the request with another POST call.  response.sendRedirect would not work in this scenario and I have often been forced to render a blank page that would post itself as soon as it is loaded.

I was curious to know if there is a more elegant way to do this and checked up HTTP 1.1 specification.  To my surprise, 302 status code which is predominantly used for response.sendRedirect requests does not explicitly state that the second request be made over GET.   The specification seems to suggest that the original method should be used for the second request as well.   But no http client that I know of does this.   302 response for a POST request is always followed by a GET request to the new resource.   And, there is another status code 303 to always do a GET for the second call.   In other words, according to specifications, 302 is expected to work the way I desired but no modern browsers support it.   Having said that, the specification acknowledges this fact and also doesn’t unambiguously state that the same method be used for the second call after a 302 response.  You can read the complete text here.

I did some more research on this and came across this post, which confirmed by findings.

- To have a guaranteed POST-REDIRECT-GET behavior, server should respond with a 303, NOT 302.

-  Ideally, POST-REDIRECT-POST should be possible with a 302, possibly with a warning to end user.  But in practice, this behavior is not supported by any of the popular browsers.

How to set up UTF-8 encoding for URIs in JBoss and Tomcat

I was surprised to find out Jboss (Tomcat) servlet container does not use UTF-8 URI encoding by default.   What this means is, in a web application running under JBoss or Tomcat, query strings in GET requests that contain multi-byte UTF-8 encoded characters (Chinese or Japanese characters, for example) will not be decoded accurately on server side.

I ran into this issue on the target page of a POST-REDIRECT-GET invocation.  The requirement was to display some user data on the target page and the data was being passed as query string of the GET call.  I could see that the query string was properly URI-encoded, but it was not getting displayed properly on the target page.  Upon investigating, I figured out this is neither an application bug  nor a limitation of the web framework that was being used (Struts 2 in this case).  The culprit was JBoss’s servlet container, which was not using UTF-8 decoding on query strings.

Here is how you fix this problem.  Locate server.xml configuration file used by the JBoss server.  You will find it under <JBoss home>/server/<server-name>/deploy/jboss-web.deployer.  If you are using plain Tomcat, you will find this under <Tomcat home>/conf.   Add the attribute URIEncoding=”UTF-8″ to the appropriate connector element and re-start the server.  That should do the trick!

Servlet 3!

I can’t wait to see Servlet 3.0 in action.  More details about the specification and the current status is available in its JSR homepage. The introduction of support for non-blocking I/O takes Java Servlets to a new level and this, in my opinion,is the most significant stride in Servlet specification since it was introduced.  The benefits opened up by this new feature are several.  Here are some I can think of -

1) If a request requires a remote call that can take significant time, servlet container does not have to maintain a dedicated thread as the web tier waits for the service to complete.

2) In case of a multi-part file upload, servlet container does not have to maintain a dedicated thread as the file is being uploaded over a slow network.

3) It is possible to have a Comet-style application, that keeps a client connection open and periodically pushes content on to client thus avoiding the need for client to poll for data.

Servlet 3.0 will be officially part of Java EE 6.  The final version of Java EE 6 specifications are expected sometime this year and it would take a while for the application servers to be fully compliant with it.  So we are looking at atleast a year or two before I can convince people in my company to use this.  Sometimes, it’s so exciting to see a new technology introduced, but yet frustrating that it will take a while before I can really start using it.  This is part and parcel of being in Java world and working in a cautious enterprise environment.

Google chrome and privacy concerns

Google Chrome has received widespread attention since it was lanuched a short while ago.  There have been good and bad things written about the beta version of chrome.   Here is my take about one of the allegations against chrome that it invades the privacy of its users.  I read some articles about this including this one.

In my opinion, these criticisms are overblown.  Let’s get this straight – google is not a charity organization.  They are fundamentally a profit-seeking company like any other corporate under the sun and launch their products to expand their business and eventually maximize the profits for their share holders.  So when they offer something for free, it actually doesn’t really come free and I don’t have a problem with it as long as they don’t claim otherwise.   I do expect them to extract something out of me for using their free product.

And, even before chrome was launched, they had so much information about you, the google-addicted user that has the tendency to “google” anything and everything.  A browser would be a perfect tool for them to close out the missing pieces and gain complete grip over the usage pattern and other interesting information about the browsing habits of web user.   And you know what? I don’t really care about it.  Maybe, I will when google becomes as big as Microsoft and start stifling its competitors by unfair means.  At this point, what really matters to me is that Google’s is still delivering user-friendly, innovative and quality products.   I am not really bothered by whatever information that Google is extracting out of my  browsing habits.    At an individual level, there is nothing for me to get scared of anyway.   It’s not like I am handing out my bank account or credit card information and so I don’t really   And, this loss of privacy is what I will be paying to get to use an innovative browser software and to experience faster browsing, assuming Chrome lives up to its initial hype.

Deleting a cookie on server side in a J2EE application

There is no direct method offered by servlet API to delete a cookie on server side. This is how you can go about doing it.

1) Loop through the cookies in the request object to locate the one that you want to delete.

for (Cookie cookie: request.getCookies()) {
    if (USER_COOKIE_NAME.equals(cookie.getName())) {
         return cookie;
    }
}

2) Set the maxAge property of the cookie to 0. This results in cookie expiring with immediate effect as soon as the client receives the response.

3) Optionally, set the value property to empty string.  This is not really required since the cookie is about to be expired.   However, this adds a sense of a clean and complete erasure if the cookie being deleted carries some critical, secure data.

4) Add this cookie to response. The cookie will be gone once the response is sent back to client!

cookie.setMaxAge(0);
cookie.setValue("");
response.addCookie(cookie);

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!