You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Hans Ulrich Niedermann <nd...@n-dimensional.de> on 2001/05/06 01:22:06 UTC
[C2] Sitemap Components, Content-Negotiation and Caching
Hi all,
if you think this is not relevant before the beta release, please tell
me. If this issue is not just a matter of missing docs or lack of
understanding by myself, I think this could cause a minor but
necessary change to some interfaces within the components' request
handling.
The Problem
===========
Multiple sitemap components within a pipeline may consider multiple
aspects ("dimensions") of a request. A HTTP server must/should tell
the client (be it user agent or cache) which aspects the delivered
data depends on. The means to tell this is the HTTP/1.1 "Vary:"
header.
However, there seems to be no mechanism in Cocoon 2 by which the
components can set the "Vary:" header in a cooperative fashion to
correctly reflect all considered aspects.
Reference and Notions
=====================
RFC 2616 Chapter 14.44 Vary http://www.rfc-editor.org/rfc/rfc2616.txt
The different aspects according to which a resource may be rendered
are called dimensions in these RFCs. These dimensions usually are HTTP
headers ("Accept", "Accept-Language", "Accept-Encoding",
"User-Agent"), but also a "*" for non-HTTP dependencies are allowed in
a "Vary:" header.
How I arrived with this
=======================
During the last few days I wanted to implement HTTP/1.1 content
negotiation for selecting the correct language using Cocoon 2.
I searched the C2 source tree for "Vary" and "negot" and came up with
2 references to "Vary", one each in HostSelectorFactory and
BrowserSelectorFactory.
But I think it is perfectly reasonable to have a resource with
language-dependent content and user-agent-dependent HTML code. This
could be achieved using org.apache.cocoon.acting.LangSelect and a
BrowserMatcherFactory or BrowserSelectorFactory.
As I understand HTTP, this should be signalled by issuing a HTTP
header "Vary: Accept-Language, User-Agent".
But how could/should different sitemap components (selectors,
generators, actions, transformers, matchers) achieve this?
I'm afraid I don't understand the sitemap/component architecture well
enough to answer that question by myself. Can you?
Conclusion
==========
Draw you own :-)
Gruß,
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Sitemap Components, Content-Negotiation and Caching
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> On Mon, 7 May 2001, Carsten Ziegeler wrote:
>
> > > > The Problem
> > > > ===========
> > > >
> > > > Multiple sitemap components within a pipeline may consider multiple
> > > > aspects ("dimensions") of a request. A HTTP server must/should tell
> > > > the client (be it user agent or cache) which aspects the delivered
> > > > data depends on. The means to tell this is the HTTP/1.1 "Vary:"
> > > > header.
> > > >
> > > > However, there seems to be no mechanism in Cocoon 2 by which the
> > > > components can set the "Vary:" header in a cooperative fashion to
> > > > correctly reflect all considered aspects.
> > >
> > > naively speaking, i'd reckon that it'd be the job of the
> cache manager to
> > > set the HTTP/1.1 Vary header. components can (and do, right?) tell the
> > > cache manager what variables upon which they vary. i think
> right now it's
> > > done on an ad hoc basis throughout the components. i reckon
> carsten would
> > > know a bit better?
> > >
> > Yes, this is correct. Each component knows on which aspects it depends.
> > So this component is currently responsible for setting the
> correct headers.
> > For example the BrowserSelector sets the "Vary: User-Agent" header etc.
> > If a component depends on other values it has to set them by
> itself. This
> > is the only working solution right now.
>
> but the components _do_ tell the cache manager what variables they vary
> on, right? so it should be possible for the cache manager to take over
> this job?
>
Yes, the components give the CacheValidity objects to the manager, telling
on what variables (input) they vary.
But the manager has (currently) no knowledge about these objects. They
are never checked or something like that. This might be a useful extensions
to the current manager.
carsten
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2] Sitemap Components, Content-Negotiation and Caching
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 7 May 2001, Carsten Ziegeler wrote:
> > > The Problem
> > > ===========
> > >
> > > Multiple sitemap components within a pipeline may consider multiple
> > > aspects ("dimensions") of a request. A HTTP server must/should tell
> > > the client (be it user agent or cache) which aspects the delivered
> > > data depends on. The means to tell this is the HTTP/1.1 "Vary:"
> > > header.
> > >
> > > However, there seems to be no mechanism in Cocoon 2 by which the
> > > components can set the "Vary:" header in a cooperative fashion to
> > > correctly reflect all considered aspects.
> >
> > naively speaking, i'd reckon that it'd be the job of the cache manager to
> > set the HTTP/1.1 Vary header. components can (and do, right?) tell the
> > cache manager what variables upon which they vary. i think right now it's
> > done on an ad hoc basis throughout the components. i reckon carsten would
> > know a bit better?
> >
> Yes, this is correct. Each component knows on which aspects it depends.
> So this component is currently responsible for setting the correct headers.
> For example the BrowserSelector sets the "Vary: User-Agent" header etc.
> If a component depends on other values it has to set them by itself. This
> is the only working solution right now.
but the components _do_ tell the cache manager what variables they vary
on, right? so it should be possible for the cache manager to take over
this job?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Sitemap Components, Content-Negotiation and Caching
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
>
> On 6 May 2001, Hans Ulrich Niedermann wrote:
>
> > if you think this is not relevant before the beta release, please tell
> > me. If this issue is not just a matter of missing docs or lack of
> > understanding by myself, I think this could cause a minor but
> > necessary change to some interfaces within the components' request
> > handling.
> >
> > The Problem
> > ===========
> >
> > Multiple sitemap components within a pipeline may consider multiple
> > aspects ("dimensions") of a request. A HTTP server must/should tell
> > the client (be it user agent or cache) which aspects the delivered
> > data depends on. The means to tell this is the HTTP/1.1 "Vary:"
> > header.
> >
> > However, there seems to be no mechanism in Cocoon 2 by which the
> > components can set the "Vary:" header in a cooperative fashion to
> > correctly reflect all considered aspects.
>
> naively speaking, i'd reckon that it'd be the job of the cache manager to
> set the HTTP/1.1 Vary header. components can (and do, right?) tell the
> cache manager what variables upon which they vary. i think right now it's
> done on an ad hoc basis throughout the components. i reckon carsten would
> know a bit better?
>
Yes, this is correct. Each component knows on which aspects it depends.
So this component is currently responsible for setting the correct headers.
For example the BrowserSelector sets the "Vary: User-Agent" header etc.
If a component depends on other values it has to set them by itself. This
is the only working solution right now.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Sitemap Components, Content-Negotiation and Caching
Posted by Donald Ball <ba...@webslingerZ.com>.
On 6 May 2001, Hans Ulrich Niedermann wrote:
> if you think this is not relevant before the beta release, please tell
> me. If this issue is not just a matter of missing docs or lack of
> understanding by myself, I think this could cause a minor but
> necessary change to some interfaces within the components' request
> handling.
>
> The Problem
> ===========
>
> Multiple sitemap components within a pipeline may consider multiple
> aspects ("dimensions") of a request. A HTTP server must/should tell
> the client (be it user agent or cache) which aspects the delivered
> data depends on. The means to tell this is the HTTP/1.1 "Vary:"
> header.
>
> However, there seems to be no mechanism in Cocoon 2 by which the
> components can set the "Vary:" header in a cooperative fashion to
> correctly reflect all considered aspects.
naively speaking, i'd reckon that it'd be the job of the cache manager to
set the HTTP/1.1 Vary header. components can (and do, right?) tell the
cache manager what variables upon which they vary. i think right now it's
done on an ad hoc basis throughout the components. i reckon carsten would
know a bit better?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org