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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
