cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] More on caching, expires, and proxy-friendly headers
Date Tue, 11 Feb 2003 16:08:26 GMT
Gianugo Rabellino wrote:

> 
> Vadim Gritsenko wrote:
> >>> ObjectModelHelper.getResponse(objectModel).addHeader("Vary",
> >>> "User-Agent");
> >>
> >> Not quite what I meant. First, I'm not sure, from the HTTP specs, 
> >> that
> >> you can have more than one Vary header, actually I think 
> it's quite 
> >> the opposite (but I might well be wrong), so an addHeader might be 
> >> dangerous (well, a setHeader might be even worse...). 
> Second (and more 
> >> important): in order to build a consistent system these 
> headers should 
> >> be set not by the sitemap components directly but by Cocoon itself,
> > 
> > 
> > 
> > I beleive this is not possible, Cocoon itself simply will not know.
> > Response can be generated using multiple things in many 
> places, and thus 
> > it will vary based upon values of those things and only 
> those places 
> > know what it was... 
> 
> I'm not saying that Cocoon should know about every possible header 
> value. But it might be worth considering, in our environment 
> abstraction, to have some kind of "policy" wrt headers.
> 
> Take the Vary case: if I'm right, only one Vary header is 
> allowed in a 
> response, so now you simply don't know what's going to happen if you 
> just "pipe" the set|addHeader calls to the real response object.
> 
> If such object was wrapped we could have a way, on Cocoon, to 
> decide if 
> and what header set. I'm still not sure that this is the way 
> to go, but 
> I start feeling that it might be worth a thought, expecially 
> if we are 
> to start implementing conditional requests.
> 

It seems you've conceptually described the 80% of the solution that is easy:
the wrapper just has to accumulate each addition in a map or similar.  The
interesting part (the 20% that takes 80% of the time) is walking these
results...  Does the spec have a BNF for the Vary header? If so, you know
that -- in theory -- it is possible to build a state machine or some other
grammar handler that can walk the map (even if it has to sort it into an
intermediate tree).


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


Mime
View raw message