Unico Hommes wrote:

<snip/>

CallFunctionNode.java ln 166/184:
// FIXME (SW) : is a flow allowed not to redirect ?

;-D


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 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.


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).

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

--
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com




Reply via email to