HEAD command not setting content-type in response under certain circumstances

We weren't able to duplicate the null content type, but suspect that this could be caused by the GzipFilter. I've just committed a patch to disable the GzipFilter for HEAD requests (it was causing some other tiny issues as well).

But to be sure, a simple test case which reproduces this issue reliably would be very helpful for us to make sure we did get it!

cheers

Athena, thanks for taking a look at this. I've asked one of the UI developers to write up simple test app, but basically, you have a webstart jnlp file that downloads a versioned jar.

Also, there's can you attach the patch so that I can test it out here?

nm about the patch. Found it. Will let you know.

1. Installation instructions (on Linux)

copy the tarball to a pristine jetty webapps/test directory

untar it:

tar zxf testcase.tar

This contains some example files that show the problem in the "webstart" directory, the jnlp download servlet, and a patch for the web.xml file

patch the web.xml file:

patch -p0 < web-xml.patch

And, you'll find that once you've done that, you can issue a HEAD command on any file in that webstart directory, and it will return with just the RESPONSE, and the Content-Length of 0 and the Server header:

mattrose@coltrane:~$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /webstart/Notepad.jnlp HTTP/1.0

HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(6.1.18)

Connection closed by foreign host.
mattrose@coltrane:~$ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /webstart/index.html HTTP/1.0

HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(6.1.18)

Connection closed by foreign host.

This is what the debug log looks like, as you can see, GzipFilter isn't even in the filter chain.

2009-08-25 13:00:17.467::DEBUG: REQUEST /webstart/N-central/jrcc-1.5.jar on org.mortbay.jetty.HttpConnection@f9e48
2009-08-25 13:00:17.468::DEBUG: sessionManager=org.mortbay.jetty.servlet.HashSessionManager@3a9bba
2009-08-25 13:00:17.468::DEBUG: session=null
2009-08-25 13:00:17.468::DEBUG: servlet=JnlpDownloadServlet
2009-08-25 13:00:17.468::DEBUG: chain=null
2009-08-25 13:00:17.468::DEBUG: servlet holder=JnlpDownloadServlet
2009-08-25 13:00:17.469::DEBUG: loaded class jnlp.sample.servlet.ErrorResponseException from ContextLoader@ui(...)
2009-08-25 13:00:17.487::DEBUG: loaded class jnlp.sample.servlet.ResourceCatalog$1 from ContextLoader@ui(...)
2009-08-25 13:00:17.519::DEBUG: loaded class jnlp.sample.servlet.DownloadResponse$JnlpErrorResponse from ContextLoader@ui(...)
2009-08-25 13:00:17.522::DEBUG: loaded class jnlp.sample.servlet.DownloadResponse$HeadRequestResponse from ContextLoader@ui(...)
2009-08-25 13:00:17.523::DEBUG: RESPONSE /webstart/N-central/jrcc-1.5.jar 200
2009-08-25 13:00:25.376::DEBUG: uri=
2009-08-25 13:00:25.376::DEBUG: fields=^M

2009-08-25 13:00:25.376::DEBUG: EXCEPTION
HttpException(400,null,null)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:361)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
2009-08-25 13:00:25.379::DEBUG: BAD

Thanks for the test case. I'm getting an error when I try to run it, though, on a pristine Jetty 6.1.18 distribution:

ayao@ayao-laptop:~$ telnet localhost 8080
Trying ::1...
Connected to localhost.
Escape character is '^]'.
HEAD /webstart/Notepad.jnlp HTTP/1.0

HTTP/1.1 500 Internal Server Error
Content-Length: 0
Server: Jetty(6.1.18)

And in the server log:
2009-08-26 17:17:30.873:/:WARN: Internal error:
java.lang.NullPointerException
at jnlp.sample.servlet.JarDiffHandler.isJavawsVersion(JarDiffHandler.java:160)
at jnlp.sample.servlet.JnlpDownloadServlet.constructResponse(JnlpDownloadServlet.java:178)
at jnlp.sample.servlet.JnlpDownloadServlet.handleRequest(JnlpDownloadServlet.java:111)
at jnlp.sample.servlet.JnlpDownloadServlet.doGet(JnlpDownloadServlet.java:79)
at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:281)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:724)
....

Seems completely unrelated, but have you run into this error before?

And hmm, I agree that GzipFilter doesn't seem involved after all. It was an educated guess on our part based on its effects on the content length when using HEAD, but that looks now to be an unrelated issue. So on to the next theory!

I've been playing around with the testcase a little bit more, and I've figured out a slightly better configuration. I'll attach the files and some more instructions.

It seems like HEAD requests are not being passed on to the JNLP download servlet properly. GET requests work fine, but the response to HEAD requests do not have the same headers that GET responses do. I looked around in the jnlp download servlet, and the code looks good there, and it used to work in Jetty-6.1.9, and there's nothing that's changed in that servlet.

this is 3 of the 4 files I have installed on a build of the jetty-6 branch I checked out yesterday. This same configuration should work for jetty-6.1.18

jnlp-servlet.jar goes in $JETTY_HOME/lib
Notepad.jnlp goes in $JETTY_HOME/webapps/test
Notepad__V2.0.894.jar goes in $JETTY_HOME/webapps/test/webstart
web.xml (to follow), goes in $JETTY_HOME/webapps/test/web.xml

web.xml I used

Oh, you're getting the 500 error because (I think) the jnlp-servlet.jar got corrupted somehow. I re-attached it, but any JDK from sun should also have it.

HTH

Thanks for the updates!

I've found the reason that the content-type isn't being sent – it is suppressed when a HEAD request would result in an error message (see http://fisheye.codehaus.org/changelog/jetty?cs=3472).

It's masking the presence of an actual error message – a GET of /webstart/Notepad.jnlp (from the previous example/instructions) gives me the NPE I brought up earlier (and the HEAD has a null content type) ; a GET of /Notepad.jnlp works (and so does its HEAD).

Matt,

I have changed jetty-6 trunk so that if an error is produced, you will get the full set of headers, rather than the truncated headers that would have been produced due to the changes to the error handling mentioned in Athena's previous comment.

So the situation is now that that requests to the URL /Notepad.jnlp all work and produces HTTP 200 and a full set of headers.

However, requests to /webstart/Notepad.jnlp produces an error, although with a full set of headers. The error message is reproduced below for your convenience, but I think it has nothing to do with jetty, but something to do with the configuration of the jnlp file itself:

java.lang.NullPointerException
	at jnlp.sample.servlet.JarDiffHandler.isJavawsVersion(JarDiffHandler.java:160)
	at jnlp.sample.servlet.JnlpDownloadServlet.constructResponse(JnlpDownloadServlet.java:178)
	at jnlp.sample.servlet.JnlpDownloadServlet.handleRequest(JnlpDownloadServlet.java:111)
	at jnlp.sample.servlet.JnlpDownloadServlet.doGet(JnlpDownloadServlet.java:79)
	at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:281)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:724)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
	at com.acme.TestFilter.doFilter(TestFilter.java:76)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
	at org.mortbay.servlet.UserAgentFilter.doFilter(UserAgentFilter.java:81)
	at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter.java:155)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:326)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:913)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

cheers
Jan

Fixed for jetty-6 head and jetty-7 head.