[Posting to v3 dev alias]
Alright, so after little hunting the bug appears to be in VsADapter.java
in v3 workspace.
The offending code always expects status of 200 to be returned, which is
just wrong.
dispatcher.dispath(dispatchTo, cl, req, res);
if (res.getStatus()!=200) {
sendError(res, "GlassFish v3 Error " +
res.getStatus());
}
So, when Rails writes "304 Not Modified" status, the above code returns
error! I think the intent here is to report 500 Internal Server Error
related bug.
Here is the suggested patch for this bug:
Index:
core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/VsAdapter.java
===================================================================
---
core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/VsAdapter.java
(revision 23308)
+++
core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/VsAdapter.java
(working copy)
@@ -135,7 +135,7 @@
}
dispatcher.dispath(dispatchTo, cl, req, res);
- if (res.getStatus()!=200) {
+ if (res.getStatus()==500) {
sendError(res, "GlassFish v3 Error " +
res.getStatus());
}
dispatchTo.afterService(req, res);
I have reported issue:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6512
-vivek.
Jacob Kessler wrote:
> We're redoing the way that GlassFish connects Rails and Grizzly, and
> we've noticed that although the new way works fine when Rails returns
> HTTP 200 (IE, the page displays, so we know that the basic connection
> between Rails and Grizzly is working fine), when Rails returns a 304
> Not Modified, Grizzly is transforming that into the default error page
> announcing GlassFish v3 Error 304. Part of this change was letting
> Grizzly write all of the headers, so we're just setting the headers
> within the GrizzlyResponse. Anyway, when we get our response back it
> has headers set as follows:
>
> INFO: Response received:
> INFO: Status: 304
> INFO: Headers:
> INFO: Content-Length is 0
> INFO: Cache-Control is private, max-age=0, must-revalidate
> INFO: X-Runtime is 0.07640
> INFO: Etag is "3f3b1dc3f0dc43a31689d43fbb0cb919"
> INFO: Body:
> INFO:
>
> which, to me anyway, looks like a properly-formed 304 packet. Grizzly
> returns a packet with the following:
>
> HTTP/1.1 404 Not found
> Content-length: 76
> Content-Type: text/html
> Cache-Control: private, max-age=0, must-revalidate
> X-runtime: 0.07640
> Etag: "3f3b1dc3f0dc43a31689d43fbb0cb919"
> Server: GlassFish/v3
> Date: Mon, 13 Oct 2008 18:29:39 GMT
>
> <html><head>Error</head><body><h1>
> GlassFish v3 Error 304</h1></body></html>
>
> Given that the Etag seems to be correctly being copied over, and that
> it works fine for HTTP 200s, it seems unlikely that the issue is that
> Grizzly can't read the incoming response. Do you have any idea why
> Grizzly would not be correctly serving the 304? I looked through the
> code for both special 304 handling and for something like non-200
> handling, and couldn't find anything like that.