ServletException in RequestDispatcher

[Joe Ess]

I have a servlet that uses RequestDispatcher to forward a request to one of a few destinations selected by various criteria. This works fine in our test environment, but on our production server, we occasionally get a ServletException:

    
06 Sep 2007 07:56:17,517 [               ] ERROR com.cclinic.gui.home.HomeServlet         - exception forwarding request Original response not available
javax.servlet.ServletException: Original response not available
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:121)
at com.cclinic.gui.home.HomeServlet.doSomething(HomeServlet.java:93)
at com.cclinic.gui.home.HomeServlet.doGet(HomeServlet.java:43)
at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:313)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:757)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1077)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3902)

Anyone have any ideas as to a cause for the original response not being available? I notice the javax.servlet.http.HttpServlet.doHead() call in the stack trace. Is there something weird about HEAD requests?

[Ben Souther]

The only thing I know is that an HTTP request of type HEAD is meant to only return headers.

I would think that it shouldn't matter as far as a filter is concerned.
As a quick fix, you could call request.getMethod and jump out if it is of type HEAD.

[Joe Ess]

I used telnet to send a HEAD request to our test server and was able to reproduce this problem, so that looks like the cause.
I was thinking of overriding the servlet's doHead method to return just the headers (it must be implemented to call doGet and figure the content length).
Should I just set the content length to a reasonable size or actually try to calculate it (the various destinations are database-backed JSP pages, so there's some variation in content)? Because of the error, the content length returned now is 0, and I haven't heard any complaints.

[Ben Souther]

I'm wondering if Weblogic has optimized doHead by having it return the headers immediately, discontinuing the whole request/response chain. Which would cause your filter to blow up on the way out, not the way in.

Let me know what happens when you override doHead.
[ September 06, 2007: Message edited by: Ben Souther ]

[Joe Ess]

I tried hitting a couple other pages with HEAD requests. From the server log it appears that the pages get processed, so it doesn't look like Weblogic is short-circuiting the process, but the response doesn't have the content-length header set. Odd because the URL that wasn't working was returning a 0 for content-length. I don't know what Weblogic is doing. What I think happens is that doHead() fakes a request/response pair and invokes doGet so it can size up the response. When I do the forward in my servlet, the RequestDispatcherImpl sees the response object is bogus and errors out. But that's just speculation.
I overrode doHead and HEAD requests work fine now. I set the content-length to a likely value and the date to the current time. That should satisfy the crawlers and caches that are interested in my site.
Thanks for the interest, Ben.

[Ben Souther]

Without looking at the HTTP spec to verify, I would guess that there shouldn't be a content-length header returned from a doHead request because the point is just to return the headers, no content.

Glad it's working for you.

[Ben Souther]

Originally posted by Joe Ess:
I don't know what Weblogic is doing.

Oh, the joys of closed source software. :/

[Joe Ess]

Originally posted by Ben Souther:
Without looking at the HTTP spec to verify

One of the first places I looked when I was trying to unravel HEAD requests

. . . If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

And yea, I got code-whiplash as I'm thinking "I'll just look at the source and see what they're doing. . . DAMNIT!"

[Ben Souther]

9.4 HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

So, the content-length should indicate the size of the body, IF you were to make a get request.

It looks like Weblogic's default doHead behavior isn't spec compliant.
[ September 06, 2007: Message edited by: Ben Souther ]