> -----Original Message-----
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: vrijdag 14 november 2003 18:05
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE RESULTS] FOM sendStatus/setStatus
>
>
> Unico Hommes wrote:
>
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Unico Hommes
> >>Sent: maandag 10 november 2003 12:11
> >>To: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> ><snip/>
> >
> >
> >
> >>Sylvain Wallez wrote:
> >>
> >>
> >>>Furthermore, I would like this feature to be defined at the
> >>>environment level and not only in the flowscript. Methods
> of the "cocoon" object should just be wrappers around
> features available also in regular Java code.
> >>>
> >>>
> >>These methods already exist on the environment objects:
> >>
> >>See HttpEnvironment.setStatus(), HttpResponse.setStatus() and
> >>HttpResponse.sendError().
> >>
> >
> >Hmm. It seems I was wrong on two accounts here.
> >
> >First HttpServletResponse.sendError() is specified to send an html
> >error page.
> >
> >This just means we need to use HttpServletResponse.setStatus(). Only
> >problem is the two argument version -
> HttpServletResponse.setStatus(int
> >sc, String msg) - seems to be deprecated with no replacement!
> >
> >The http spec does allow for a customized "reason phrase".
> So why this
> >was done remains a mystery to me:
> >
> >-- HTTP/1.1 (RFC 2068) --
> >
> >6.1.1 Status Code and Reason Phrase
> >
> >....
> >
> >The reason phrases listed here are only recommended
> > -- they may be replaced by local equivalents without affecting the
> > protocol.
> >
> > Status-Code = "100" ; Continue
> > | "101" ; Switching Protocols
> > | "200" ; OK
> >
> >-- /HTTP/1.1 (RFC 2068) --
> >
> >What do you think? Should we skip the two argument
> sendStatus/setStatus
> >methods? Or should we ignore the deprecated warning from the
> servlet api?
> >
> >
>
> Reading carefully the Javadoc, sendError() and setStatus() are very
> different:
>
> - sendError() sends an error page and commits the response
> (nothing more
> can be sent). The string parameter is the HTML snippet that
> is displayed
> in the browser, but not the reason phrase. And this snippet can
> eventually be overriden if an error page associated to the
> status code
> is declared in web.xml
>
> - setStatus() only sets the response status, but does not commit the
> response, meaning the application can send content afterwards.
>
Exactly.
> And you're right, the servlet API gives us no way to specify
> the reason
> phrase (even the deprecated method, in which the string is
> the same HTML
> snippet as above). But is it really usefull?
>
I was starting to question that as well. The main reason I thought it
would be useful was in 409 - "Conflict" situations, since the WebDAV
spec was saying that the server should provide information to the client
so that it can recover. But now looking at the HTTP/1.1 spec I see that
such information is supposed to be send in the response body.
I think we can just skip it for the moment until somebody comes up with
a valid use case.
> >The isRedirected flag still needs to be set on the Redirector upon
> >sendStatus(). We need to decide how. We can do this by
> specifying null
> >as the url argument to the redirect methods:
> >
> >package o.a.c.environment;
> >
> >interface Redirector {
> >
> > /**
> > * Redirect to the given URL, null only sets the
> > * isRedirected flag.
> > */
> > void redirect(boolean sessionMode, String url);
> >
> > /**
> > * Unconditionally redirect to the given URL, null only
> > * sets the isRedirected flag.
> > */
> > void globalRedirect(boolean sessionMode, String url);
> >
> >}
> >
> >Or we can add a special nullRedirect() method.
> >
> >
>
> Mmmh... do you mean that we'll have to call both
> response.sendStatus()
response.setStatus()
> and redirector.redirect(null)? This looks hacky...
>
> Moreover, I think we should keep the barriers of Cocoon's response
> object that forbid access to the underlying response outputstream or
> also forbid sending redirects from pipeline components. This is why
> Redirector was created for: allow to those components that have the
> right to do it (actions, and now flowscript) to send
> content-less responses.
>
> Up to now these content-less responses were limited to
> redirects, and I
> think that sendStatus() would be best located on Redirector.
>
> This would solve all problems at once:
> - no possibility to tweak the status from within a pipeline
> - have a central object that gathers all methods used to send
> content-less responses.
>
> WDYT?
>
Yes this sound fine to me. I'll go with that.
Unico
