cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject Improving HTTP protocol handling (Was: RE: Fooling around with cocoon davmap)
Date Mon, 03 Nov 2003 10:29:25 GMT
> -----Original Message-----
> From: Sylvain Wallez [] 
> Sent: maandag 3 november 2003 9:52
> To:
> Unico Hommes wrote:
> <snip/>
> >
> >We were talking about the fact that it seemed impossible to 
> serve a request without also sending an entity body along 
> with the response. (Short of suppressing the output in the 
> serializer which is more of hack than a solution). I thought 
> it was allowed to call a flow function and then not send a 
> page. But apparently was wrong. Stefano agreed that it should 
> be legal to call a flow function that does not redirect to a 
> page in order to cover the full range HTTP better.
> >
> >Specifically we were discussing the specification of the 
> OPTIONS method that prescribes that "the response MUST NOT 
> include entity information other than what can be considered 
> as communication options" which seems to exclude sending an 
> entity body from being such a legal response.
> >
> >I traced the above location as the place the code would need 
> to be changed in order to achieve this. But I could be wrong.
> >  
> >
> Sorry to say that, but... yes, I think so ;-)
> IMO, this should be handled at the pipeline level, i.e. on a 
> HEAD request, the pipeline should be built and setup, but not 
> executed. And this for several reasons:
> - not every request is handled by flowscript
> - some pipeline components set response headers, such as the 
> i18n transformer or the browser selector.
> - if we use the pipeline key as the Etag (see below), the 
> pipeline must be built and setup to compute that key.

Good point, we need to do that too, but not having to send a page from
the flow could also help us in other situations where we don't need
access to the pipeline. Think OPTIONS, TRACE, MKCOL, PUT, etc. Or do you
think these should also be handled at the pipeline level?

> Note that this pipeline-level handling is different from 
> fooling the serializer by sending its output to /dev/null, 
> since the processing chain is setup to get all required 
> information, but not executed.
> Actually, this is not very different from what happens today 
> when content is retrieved from the cache (pipeline is built 
> and setup but not executed).

OK. Are you saying then that the pipelines should be handling more low
level HTTP methods? Or do you see some other specialized component
handling this?

> >>BTW, can someone explain me what ETags are about (read that 
> in the http RFC a long time ago, but did not really 
> understood at that time).
> >>    
> >>
> >
> >I just looked. It seems entity tags are used as cache 
> validators, similar to Last-Modified header I guess, i.e. 
> they encode the state of a resource entity so that clients 
> can optimize network calls by sending along headers like 
> If-Match, If-None-Match, If-Range, that are then be checked 
> against the current value of the entity tag on the server. If 
> they match (or not) the method is executed. At least that's 
> what I got out of it.
> >  
> >
> Don't really understand what resource _entity_ means, 

      The information transferred as the payload of a request or
      response. An entity consists of metainformation in the form of
      entity-header fields and content in the form of an entity-body, as
      described in section 7."

> but it 
> looks like the pipeline cache key could be used for the ETag. 
> What do you think?

I think so. The spec talks about weak and strong entity tags. I would
say the pipeline cache key qualifies as a weak one. Weak keys only
approximate semantic equivalence whereas strong keys reflect the
verbatim response. Because although the pipeline output may stay the
same it doesn't include information about the values of the response
headers, and because validity object the pipeline gets from the pipeline
components doesn't state the content wouldn't be different if it would
execute the pipeline again, just that it shouldn't execute the pipeline.

> Sylvain
> -- 
> Sylvain Wallez                                  Anyware Technologies
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, 
> Projects } Orixo, the opensource XML business alliance  -  

View raw message