Well, Jetty certainly uses the unwrapped requests when sendError is called.

However, it does invoke the error page mechanism during the call to sendError and thus while
within the scope of the original filters. It does this because of the language in : SRV.9.9.2

"If the sendError method is called on the response, the container consults the
list of error page declarations for the Web application that use the status-code
syntax and attempts a match. If there is a match, the container returns the resource
as indicated by the location entry."

This indicates that error handling for sendError should take place during the call - thus
the error filters get applied then.... but on the unwrapped request and response.

What is not defines is if the Default servlet should use sendError or not for a 404 - but
it would appear a reasonable choice.

Anyway, I will raise this with the servlet EG and see what they have to say....

Tomcat and Sun Java Application Server invoke error page mechanism outside the scope of the original filters.
sendError in them only marks response as error-response and disables modifying of the response by web-application.
And error handling is processed after exiting from all filters (and applying filters with <dispatcher>ERROR</dispatcher> of course).

it isn't absolutely clear to me from Servlet Specification whose approach is correct, but request and response cannot be called unwrapped/unfiltered (n.b. UNFILTERED) in sendError.

Same issue in Resin: http://bugs.caucho.com/view.php?id=1325

I've just observed that Jetty is showing a built-in 404 error page instead of the custom page I defined in the web.xml. Could this be related to this issue?

Still no feedback from the servlet-EG.
Will push again.

Looks like this is fixed in 6.1.0pre3?

Greg, what's the status on this one? Can you resolve or close it if appropriate?

Tested in 6.1.2rc2, works.

Oops, sorry for last comment. This bug is still open.

Marat,

the only response I have gotten from the servlet EG is from IBM who
confirmed that webshere is implemented the same way as Jetty and Resin...
ie the page is invoked during sendError call.

I have raised it as ISSUE 37 in the EG and may be addressed in the next major
release. But for servlet 2.5 I think you need to consider this an ambiguity
and your webapp will need to be able to cope with both approaches if it
is to be portable.

won't fix unless guided by

https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=37

I see, Greg. Anyway, thanks for help

Sorry for reopening. I hit this issue today again (jetty-6.1.22) and was curious about its status. I cannot access the link you gave [1] since I don't have permissions to view servlet-spec-eg project (strange decision to keep spec development in private, but whatever).

Was it addressed in servlet api 2.5? If yes, then this bug is valid and should be fixed in jetty 6.1.x (which claims to support servlet api 2.5). If no, was it addressed in servlet api 3.0? If yes, is it fixed in jetty 7.0.x? If neither of above, specify other option

[1] https://servlet-spec-eg.dev.java.net/issues/show_bug.cgi?id=37

Marat,

firstly do apologize needed for reopening issues - that's what the reopen button is for!

But in this case I'm closing it again as nothing will change for 2.5 nor did it make it into 3.0.

I also think you are misunderstanding the implications of SRV.9.9.3. This sections says only that the unwrapped request/response will be used when
dispatching for the error page. It does not say anything about when the dispatch will take place.

Jetty uses the unwrapped request, so it does comply with SRV.9.9.3.

Jetty (and some other containers) do the error dispatch from within the call to sendError, as is indicated by SRV9.9.2. Some other containers defer the error dispatch until after the original dispatch has completed. Neither approach can be said to be correct because the spec just not clear enough - although I think SRV9.9.2. and the javadoc for sendError lean towards the jetty approach.

There has been no comment by the EG on Issue 37, which I raised, so I think we must conclude that at this stage, there is no interest in resolving this ambiguity in the specification.

I think that they only way to proceed is that your code has to be prepared for either execution order. The error dispatch may occur within sendError or it may occur afterwards.