Stefano Mazzocchi wrote:
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?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.
Question: (and an important one)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). ù
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?
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. :-)
Actually the "grammar" for that "production" is<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?
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
