Activity

This appears to be that the common HTTPServer class is setting the content-type in the doFilter routine first, then later jersey sets it to what it actually is. Instead of over writing it, it appears to append it. Need to investigate fix.

Thomas Graves
added a comment - 03/Jan/12 18:16 This appears to be that the common HTTPServer class is setting the content-type in the doFilter routine first, then later jersey sets it to what it actually is. Instead of over writing it, it appears to append it. Need to investigate fix.

No way to easily unit test this as we would have to start up the entire httpserver with the yarn web app framework and all, so no tests were added. The existing webservice tests will verify nothing was broken. I manually tested all the webservice calls via curl to make sure only the xml/json content type came out.

Thomas Graves
added a comment - 25/Apr/12 19:51 No way to easily unit test this as we would have to start up the entire httpserver with the yarn web app framework and all, so no tests were added. The existing webservice tests will verify nothing was broken. I manually tested all the webservice calls via curl to make sure only the xml/json content type came out.

I don't really like the fix because it requires all of the jersey methods to be modified, in exactly the same way, but that is the exact same fix as HDFS-2441 did so I guess it is OK.

The root of the issue appears to be that HttpServer.QuotingInputFilter is trying to guess what the content type is based off of the URI of the request, and always setting it no matter what. This seems to be so that we can set the charset of the response to be utf-8. This is coupled with Jersey also outputting the content type instead of overwriting the one that was set previously.

Also it makes it more difficult for them to be called as regular methods. I really would prefer to see something with the server where we could fix some of this in HttpServer itself so that we don't get the automatic content type for web services. But that is likely to be a bigger change and would be a bit more cross project. Sadly I tried upgrading to Jersey 1.12 and it does not fix the issue.

Robert Joseph Evans
added a comment - 25/Apr/12 21:24 I don't really like the fix because it requires all of the jersey methods to be modified, in exactly the same way, but that is the exact same fix as HDFS-2441 did so I guess it is OK.
The root of the issue appears to be that HttpServer.QuotingInputFilter is trying to guess what the content type is based off of the URI of the request, and always setting it no matter what. This seems to be so that we can set the charset of the response to be utf-8. This is coupled with Jersey also outputting the content type instead of overwriting the one that was set previously.
Also it makes it more difficult for them to be called as regular methods. I really would prefer to see something with the server where we could fix some of this in HttpServer itself so that we don't get the automatic content type for web services. But that is likely to be a bigger change and would be a bit more cross project. Sadly I tried upgrading to Jersey 1.12 and it does not fix the issue.
So reluctantly I give this a +1.