Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 89408 invoked from network); 3 Nov 2003 00:58:03 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 3 Nov 2003 00:58:03 -0000 Received: (qmail 1896 invoked by uid 500); 3 Nov 2003 00:57:45 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 1650 invoked by uid 500); 3 Nov 2003 00:57:44 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 1636 invoked from network); 3 Nov 2003 00:57:43 -0000 Received: from unknown (HELO naomi.webworks.nl) (24.132.161.79) by daedalus.apache.org with SMTP; 3 Nov 2003 00:57:43 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fooling around with cocoon davmap Date: Mon, 3 Nov 2003 01:57:50 +0100 Message-ID: <84F0A43A4248CE45B5C0E20F4C40779C36CC60@naomi.webworks.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fooling around with cocoon davmap Thread-Index: AcOhiDalDYWCn0BwQpuHCBUtBHQUsQADNBCg From: "Unico Hommes" To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: >=20 > Unico Hommes wrote: >=20 > >Sylvain Wallez wrote: > > > > > >>Unico Hommes wrote: > >> >=20 > >=20 > >>>I just had a look at the code, seems it was already a FIXME on > Sylvain's list. Can I go ahead and make this change? > >>> > >>> > >>Uh? Where's that list?? > >> > >> > > > > > >CallFunctionNode.java ln 166/184: > >// FIXME (SW) : is a flow allowed not to redirect ? > > > >;-D > > > > >=20 > 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. >=20 > Sorry, but I don't see how this relates to HEAD, ETags et al... What was > the change you proposed to do? >=20 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. > 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). >=20 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. -- Unico > Sylvain >=20 > -- > 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 >=20