cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Fooling around with cocoon davmap
Date Mon, 03 Nov 2003 08:52:21 GMT
Unico Hommes wrote:


>>> ln 166/184:
>>>// FIXME (SW) : is a flow allowed not to redirect ?
>>Uh (again)? I'm wondering if there's not a misunderstanding here: this FIXME is about
knowing if a flowscript is allowed to terminate without stating what page it to be displayed,
i.e. check if one of sendPage(), sendPageAndWait() or redirectTo() was called.
>>Sorry, but I don't see how this relates to HEAD, ETags et al... What was the change
you proposed to do?
>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
>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
>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.

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 

>>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, but it looks like 
the pipeline cache key could be used for the ETag. What do you think?


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

View raw message