You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2008/01/28 15:38:53 UTC
SLING-207: HTTP status code for included requests
Hi,
See SLING-207, in an ESP script like this one:
<body>
<%
sling.include(resource.getPath() + ".html");
%>
</body>
The include rightly causes a server error due to the (just added)
SLING-208 infinite loop detection.
However, client receives a status 200 OK in this case. Do we want that?
For some status codes, say if the included request causes a 404, it
might make sense to still return 200 for the page request, but I think
a 500 should be relayed to the client.
-Bertrand
Re: SLING-207: HTTP status code for included requests
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Dienstag, den 29.01.2008, 08:41 +0100 schrieb Bertrand Delacretaz:
> On Jan 29, 2008 8:28 AM, Felix Meschberger <fm...@gmail.com> wrote:
>
> > ...If the response has already been committed at the time the infinte loop
> > detection aborts processing, it is not possible to send 500 any more....
>
> In my case it is not committed yet - I added a check for isCommitted()
> in Response.setStatus(), and that doesn't bark.
>
> > ...In the Servlet API it is not allowed for included requests
> > to set headers (I understand this such that included requests are also
> > not able to set the response status code), while in Sling this
> > restriction does not exist....
>
> Ok, so the 500 should work in my example, I'll investigate further.
>
> That might be a case where the HttpStatusCodeException that we had in
> microsling might come handy ;-)
Yep .... On the other hand throwing a SlingException (or better an
extension thereof) should actually get through up to the outermost
SlingMainServlet.service method and be handled with a 500. If not, this
would be an implementation issue in the SlingMainServlet.include method
eating up SlingExceptions (or RuntimeExceptions at large)
Regards
Felix
Re: SLING-207: HTTP status code for included requests
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 29, 2008 8:28 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...If the response has already been committed at the time the infinte loop
> detection aborts processing, it is not possible to send 500 any more....
In my case it is not committed yet - I added a check for isCommitted()
in Response.setStatus(), and that doesn't bark.
> ...In the Servlet API it is not allowed for included requests
> to set headers (I understand this such that included requests are also
> not able to set the response status code), while in Sling this
> restriction does not exist....
Ok, so the 500 should work in my example, I'll investigate further.
That might be a case where the HttpStatusCodeException that we had in
microsling might come handy ;-)
-Bertrand
Re: SLING-207: HTTP status code for included requests
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I agree, that returning 500 might be desirable, but ....
If the response has already been committed at the time the infinte loop
detection aborts processing, it is not possible to send 500 any more.
There is also a difference in request inclusion between Sling and the
Servlet API: In the Servlet API it is not allowed for included requests
to set headers (I understand this such that included requests are also
not able to set the response status code), while in Sling this
restriction does not exist.
Regards
Felix
Am Montag, den 28.01.2008, 15:38 +0100 schrieb Bertrand Delacretaz:
> Hi,
>
> See SLING-207, in an ESP script like this one:
>
> <body>
> <%
> sling.include(resource.getPath() + ".html");
> %>
> </body>
>
> The include rightly causes a server error due to the (just added)
> SLING-208 infinite loop detection.
>
> However, client receives a status 200 OK in this case. Do we want that?
>
> For some status codes, say if the included request causes a 404, it
> might make sense to still return 200 for the page request, but I think
> a 500 should be relayed to the client.
>
> -Bertrand