Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

ServletException in RequestDispatcher  RSS feed

 
Joe Ess
Bartender
Posts: 9425
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 9425
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 9425
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joe Ess:
I don't know what Weblogic is doing.


Oh, the joys of closed source software. :/
 
Joe Ess
Bartender
Posts: 9425
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!