cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [VOTE RESULTS] FOM sendStatus/setStatus
Date Fri, 14 Nov 2003 17:24:32 GMT


> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: vrijdag 14 november 2003 18:05
> To: dev@cocoon.apache.org
> Subject: Re: [VOTE RESULTS] FOM sendStatus/setStatus
> 
> 
> Unico Hommes wrote:
> 
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Unico Hommes
> >>Sent: maandag 10 november 2003 12:11
> >>To: dev@cocoon.apache.org
> >>
> >>    
> >>
> >
> ><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

Mime
View raw message