Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E48FB26.9020405@apache.org>
Date: Tue, 11 Feb 2003 14:31:18 +0100
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] More on caching, expires, and proxy-friendly headers
References: <3E48D71B.7080004@apache.org> <3E48F2A0.8070006@apache.org>
In-Reply-To: <3E48F2A0.8070006@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Stefano Mazzocchi wrote:

>> Full proxy compliance depends on the ability of dealing with 
>> conditional requests, handling a bunch of request headers all in some 
>> way interdependant and tricky to say the least. I'm not saying that we 
>> shouldn't do that sooner or later, but I'd rather plan this activity 
>> carefully, and possibily together with someone (Chuck?) from the httpd 
>> group working on the proxy part, in order to ensure that things work 
>> smoothly.
> 
> 
> At ApacheCon I set with Chuck who forwarded me to another guy who's the 
> one doing the work nowadays, but I forgot who he was. But I can ask him 
> again.

I was there too, and the guy was the one that just had the presentation 
on mod_proxy. According to the ApacheCon site he should be Graham 
Legget, does that ring a bell?

> Question: (and an important one)
> 
> Suppose you have a resource like
> 
>  /images/logo
> 
> that you hit with two different user agent and that a pipeline renders 
> differently depending on the user agent, how can a proxy behave friendly 
> to this? do we have a way to specify that a specific request has to be 
> matched not only against a URI but also against the user-agent that 
> requested it?

This can be done in a theory, once (and if) we'll have real proxy 
support in place. The first thing that can be done is starting to have 
real "Etag" support: an "Etag" is an unique identifier (think checksum) 
that represents the given URI from a server side view. This means that 
the same URI can lead to different etags being generated, according to 
internal server logic (request parameters, user agents, you name it). �

Since an Etag is just a string, I guess that the cache key could do the 
job, but I'm not sure that it might be the better way security wise 
(you'll end up handing to the world your private cache keys, I'm not 
sure that this is a good thing). Also, Etags are useless if there is no 
conditional request handling: the proxy will ask Cocoon "give me that 
URI, identified by this Etag, if not modified since this timestamp": 
Cocoon must be able to analyze that query and reply either with an 304 
status code (not modified) or with a 200 with the actual content.

In this particular case, however, the cleanest solution is using the 
HTTP/1.1  "Vary:" header. This header is supposed to contain all the 
request fields that must match for a proxy to decide that a resource is 
still valid even if requested by different users. Here you can specify 
that the user-agent is one of such headers, but:

0. this is one of the most undocumented headers around;

1. you still have to support Etags too (don't really know why);

2. there is no advanced feature like regular expressions or substring 
(proxies might implement it, but it's outside your control), so slightly 
different user agents (language, version, operating systems) will lead 
to regeneration;

3. I dare you to find a clean solution from the sitemap POV to express 
this kind of conditions. :-)

>> <pipeline internal-only="true">
>>   <parameter name="expires" value="now plus 5 minutes"/>
> 
> 
> isn't something like
> 
>  <parameter name="TTL" value="5 minutes"/>
> 
> simpler to understand? we don't expect people to write
> 
>  <parameter name="expires" value="tomorrow plus 25 hours"/>
> 
> don't we?

Actually the "grammar" for that "production" is

expires := (access|modification|now)
            plus*
            (DIGIT (months|weeks|days|hours|minutes|seconds))+

(BNF experts, please bear with me ;-))

We have been discussing that in the past, and the reason for this syntax 
was compatibility with the syntax of HTTPd mod_expires. But I don't see 
any problem in changing that.

> Sounds like a good idea but I think Carsten is the one that knows the 
> caching internals better.

Definitely, I'm waiting for his Word to stop playing and start doing 
real work. :-) I have some toy code working here, but I'm still 
wondering what is the best way to refresh the expires information...

> One thing that you didn't describe is the ability for cocoon to reply to 
> proxy requests with the 'body hasn't changed' error code just by using 
> the pipeline caching logic but without having to regenerate the whole 
> thing. Is this another microstep or you have reasons against this?


As you can understand from my first comment, this is actually a hell of 
a lot of microsteps. :-) Next one will be etag support, followed by 
conditional request handling and full 304 support. From there, we'll be 
almost halfway (almost!) to full proxy-friendliness, but it won't be an 
easy task... it's no rocket science, but the spec is ankward, and it 
requires careful planning and coding.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org