RE: error-page status codes broken, no response to bugzilla report

[Donald Ball <db...@rhoworld.com>]

On 12/23/2002 at 9:40 AM Costin Manolache wrote:

>It is on my todo list ( I also need this to work, at least for 500 ).
>Do you have a patch ?

I have attached an erstwhile patch to the bug in bugzilla. It assumes the
content type of the error-page resource to be text/html and uses rd.include
instead of rd.forward to get the content body. I have a feeling that
someone more well-versed with catalina's internals could write a better
patch that gets both the http status code _and_ the content type correct,
but I am not that person.

Nonetheless, I think the patched behavior is much more correct than the
current behavior and should be applied to cvs.

- donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball <db...@rhoworld.com>]

>The key issue is that declaring an <error-page> handler ***replaces*** the
>standard container behavior; it doesn't ***augment*** it.
>
>Consider, for example, a webapp that want to implement something like what
>the "Redirect" configuration parameter does for Apache (so that old URLs
>still work).  In today's world, you can write such a thing by mapping 404
>errors to a servlet that redirects to the desired resource (which
>ultimately returns a 200) for the URLs it knows about, and just returns
>the original 404 for everything else.
>
>With your proposed change, it would not be possible to implement this
>functionality.  That would be bad.

Sure it would be possible. You could handle that case by mapping /* to a
servlet and having it do the logic - map old URLs to new URLs (with a
proper 301, not a silent internal redirect and a 200, ideally), return 404s
for everything else. I can't say if it's easier or harder than the solution
you proposed, but it definitely looks possible.

For that matter - for the solution that you propose, by a strict reading of
the servlet spec, why wouldn't you get into an infinite loop if the
location for a 404 error-page returns a 404 status code? or bounce back and
forth between 404 and 301, say? I see that tomcat avoids the first problem,
at least, but I don't see where in the servlet spec it says that it's
supposed to...

>> Regardless of what you/we decide here for tomcat, should this be brought
>to
>> the servlet expert group for clarification in a forthcoming servlet
spec?
>
>You're certainly welcome to send them mail:
>
>  servletapi-feedback@eng.sun.com
>
>and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
>still subject to correction if needed.  (And I'm going to make the above
>argument if it's brought up for discussion -- to say nothing of the fact
>that this would break backwards compatibility for loads of existing
>applications ;-).

That's certainly something to consider. Since tomcat is the reference
implementation, ambiguities in the spec are resolved by looking at its
(buggy :)) behavior, yes? I guess I really wonder what webapps rely on this
behavior and why - it seems to me that fixing tomcat to work the way I
expect would fix more webapps than it would break. However, I guess I'd be
happy if the servlet spec simply explicitly declared what's supposed to
happen so web developers who care about http, rest, etc. realize they need
to explicitly give status codes to their pretty error pages. I'll write
something in.

Thanks for your patience with this pedantic problem.

- donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: error-page status codes broken, no response to bugzilla report

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 12:49:40 -0500
> From: Donald Ball <db...@rhoworld.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>,
>      dball@rhoworld.com
> To: tomcat-dev@jakarta.apache.org, tomcat-dev@jakarta.apache.org
> Subject: RE: error-page status codes broken, no response to bugzilla   report
>
> On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote:
>
> >> Nonetheless, I think the patched behavior is much more correct than the
> >> current behavior and should be applied to cvs.
> >>
> >
> >(Sorry for being out of touch earlier -- holidays and busyness and such).
> >
> >I do not agree with the assertion that the current behavior is broken.
>
> <snip/>
>
> I read and understand that you can map error-page handlers to locations
> which in fact respond with the original status codes. Nonetheless, it still
> seems to me that the behavior is incorrect wrt the servlet spec, not to
> mention http and common sense. Again, I quote:
>
> ---
> Hmm. Digging around in the 2.3 spec more deeply, I note the description of
> HttpServletResponse.sendError reads:
>
> "Sends an error response to the client using the specified status clearing
> the buffer. The server defaults to creating the response to look like an
> HTML-formatted server error page containing the specified message, setting
> the content type to "text/html", leaving cookies and other headers
> unmodified. If an error-page declaration has been made for the web
> application corresponding to the status code passed in, it will be served
> back in preference to the suggested msg parameter."
>
> The first sentence clearly states that the response sent to the client must
> use the specified status code, regardless of whether the content body is
> generated by the server automatically or is read from an error-page
> location.
> ---
>
> It still seems to me that the status code of the error-page should be the
> status code of the response. Not only is that the behavior implied by the
> spec, but it also prevents naive web developers from writing webapps that
> return pretty error response pages tagged with status 200. The default
> behavior should be to preserve the http conversation, not to censor it. You
> argue that I should do extra work to preserve the status code. I argue that
> (if one really wanted to for some arcane reason) one should do extra work
> to hide it.
>

The key issue is that declaring an <error-page> handler ***replaces*** the
standard container behavior; it doesn't ***augment*** it.

Consider, for example, a webapp that want to implement something like what
the "Redirect" configuration parameter does for Apache (so that old URLs
still work).  In today's world, you can write such a thing by mapping 404
errors to a servlet that redirects to the desired resource (which
ultimately returns a 200) for the URLs it knows about, and just returns
the original 404 for everything else.

With your proposed change, it would not be possible to implement this
functionality.  That would be bad.

> Regardless of what you/we decide here for tomcat, should this be brought to
> the servlet expert group for clarification in a forthcoming servlet spec?
>

You're certainly welcome to send them mail:

  servletapi-feedback@eng.sun.com

and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
still subject to correction if needed.  (And I'm going to make the above
argument if it's brought up for discussion -- to say nothing of the fact
that this would break backwards compatibility for loads of existing
applications ;-).

> - donald
>

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball <db...@rhoworld.com>]

On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote:

>> Nonetheless, I think the patched behavior is much more correct than the
>> current behavior and should be applied to cvs.
>>
>
>(Sorry for being out of touch earlier -- holidays and busyness and such).
>
>I do not agree with the assertion that the current behavior is broken.

<snip/>

I read and understand that you can map error-page handlers to locations
which in fact respond with the original status codes. Nonetheless, it still
seems to me that the behavior is incorrect wrt the servlet spec, not to
mention http and common sense. Again, I quote:

---
Hmm. Digging around in the 2.3 spec more deeply, I note the description of
HttpServletResponse.sendError reads:

"Sends an error response to the client using the specified status clearing
the buffer. The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting
the content type to "text/html", leaving cookies and other headers
unmodified. If an error-page declaration has been made for the web
application corresponding to the status code passed in, it will be served
back in preference to the suggested msg parameter."

The first sentence clearly states that the response sent to the client must
use the specified status code, regardless of whether the content body is
generated by the server automatically or is read from an error-page
location.
---

It still seems to me that the status code of the error-page should be the
status code of the response. Not only is that the behavior implied by the
spec, but it also prevents naive web developers from writing webapps that
return pretty error response pages tagged with status 200. The default
behavior should be to preserve the http conversation, not to censor it. You
argue that I should do extra work to preserve the status code. I argue that
(if one really wanted to for some arcane reason) one should do extra work
to hide it.

Regardless of what you/we decide here for tomcat, should this be brought to
the servlet expert group for clarification in a forthcoming servlet spec?

- donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: error-page status codes broken, no response to bugzilla report

["Craig R. McClanahan" <cr...@apache.org>]

On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 10:26:10 -0500
> From: Donald Ball <db...@rhoworld.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>,
>      dball@rhoworld.com
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: error-page status codes broken, no response to bugzilla  report
>
> On 12/23/2002 at 9:40 AM Costin Manolache wrote:
>
> >It is on my todo list ( I also need this to work, at least for 500 ).
> >Do you have a patch ?
>
> I have attached an erstwhile patch to the bug in bugzilla. It assumes the
> content type of the error-page resource to be text/html and uses rd.include
> instead of rd.forward to get the content body. I have a feeling that
> someone more well-versed with catalina's internals could write a better
> patch that gets both the http status code _and_ the content type correct,
> but I am not that person.
>
> Nonetheless, I think the patched behavior is much more correct than the
> current behavior and should be applied to cvs.
>

(Sorry for being out of touch earlier -- holidays and busyness and such).

I do not agree with the assertion that the current behavior is broken.

The <location> that you declare inside an <error-page> element is a
context-relative URL of a web application resource that should handle this
error *instead of* the container's default handling (which would be to set
the status code and message per the HTTP spec's description).  As such, it
is totally up to your declared resource to decide what to do.

For example, you could easily define a resource URL that is mapped to a
servlet that called response.sendError() to set the ultimate error code,
plus did some other stuff.  But that is up to you to decide, not up to the
container.  The container's job is to send back whatever your application
told it to send.

If you point at a webapp resource that *itself* returns a 200 status
(which is the default behavior for static resources served by the
file-serving servlet, and which is what JSP pages will return unless you
do something different inside them), a 200 is what you should see in the
final response to the client.

If you want something different, map your error page handlers to a servlet
that does something different.

> - donald
>

Craig McClanahan



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>