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 12:00:09 GMT
Stefano Mazzocchi wrote:

> On Monday, Nov 3, 2003, at 09:52 Europe/Rome, Sylvain Wallez wrote:
>> Unico Hommes wrote:
>> <snip/>
>>>>> 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.
> not really. There are many cases in WebDAV/DeltaV/DASL where an HTTP 
> request doesn't really generate content.... but needs lots of 
> procedural logic to take care of it.

I was initially focused on HEAD, but see my later answer to Unico.


> It seems like a waste of resources to me to setup a pipeline not to 
> use it. But, I don't understand... if I have
>  <match>
>   <call function="blah"/>
>  </match>
> and then
> function blah() {
>   cocoon.response.setHeader("DAV:","1");
>   // does *NOT* call sendPage*
> }
> where is the pipeline created?

Nowhere. So we need a way to express this to disambiguate no-body from 404.


>> 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?
> Not really. The cache "key" is attached to a "versionable resource", 
> the ETag is attached to the "resource entity", means that the ETag is 
> a unique and *permanent* identifier for that particular instance of 
> that versionable resource. It is like the "version identifier" of that 
> particular resource.
> For example, using URIs, if
>  http://host/path/file
> is a versionable resource (means that we keep track of its version.. 
> in DeltaV terminology, this is "put under version control"), then
>  http://host/path/file/1.0.000
> could be its URI and it is equivalent to its ETag... no matter what 
> happens in the future, that resource is *immutable*. This is, for 
> example, like Subversion works. Note that ETags are very useful for 
> proxies: an immutable resource can be cached *forever*.

Mmmh... so this makes the cache key useless for this...

> ETags are also useful for the lost update problem when no locking 
> mechanism is in place:
>  person A does "GET / HTTP/1.1", obtains the page and an ETag
>  person B does "GET / HTTP/1.1", otainss the same page and same ETag
>  person A modifies the page (say, in linotype)
>  person B modifies the page as well (say, in OpenOffice)
>  person A does "PUT / HTTP/1.1", with header "If-Match" and the 
> previous ETag
>  [the server sees that the ETag is the same, does the saving and the 
> ETag is modified]
>  person B does "PUT / HTTP/1.1", with header "If-Match" and the ETag 
> that got originally
>  [the server returns a 409 CONFLICT because the ETag doesn't match]

Interesting how http already considers so many problems!

> see for more info on this
> [At this point, it's up to the user-agent software to know what to do]
> I'm diving deeper and deeper into this stuff (also because of JSR 170) 
> and the more I look into it, the more I think we are generally too 
> ignorant on how HTTP really works. HTTP and friends are protocols that 
> we use for, say, 5%... everything else is considered black magic and 
> reinvented everytime. Normally results in massive performance and 
> scalability limitations.
> But for Doco, I'm going to spend a serious effort to make things work 
> the way the HTTP spec says.... in order to please the HTTPD people and 
> in order to show that, no matter what web technology you use, if you 
> know how network architectures operate, you scale massively.
> But I'm going to fill this gap and, hopefully, influence you people 
> back ;-)
> And the work on the davmap is, IMO, going to trigger a lot of 
> interesting redesigns in the internals.



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

View raw message