[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Public review comments: Caching of resources - clarificationneeded
I'm not sure if copying the headers to the transport level between consumer
and producer is the right aproach as said yesterday in the call.
If we consider WSRP being a bridge using it's own transport then the
transport metadata between browser<->Consumer and
Producer<->Resource/Portlet should probably transferred on the protocol
level (or as SOAP headers?).
I think otherwise we might see some collisions here. One example that jumps
immediatly into my mind is cookies.
The producer may require the consumer to handle cookies for the sake of
WSRP communication between those two (session management/cluster routing,
SSO tokens, etc.).
Additionally portlets/resources might want to set some cookies.
These certainly will collide with he producer cookies intended to the
consumers.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
07/27/06 08:36 PM wsrp <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Public review comments:
Caching of resources -
clarification needed
In (2) below, are you suggesting that the consumer copy headers at the
transport level between the consumer and the producer? That is fine by
me, but those headers may not be relevant for the protocol in place
between the consumer and the producer.
On the ClientData suggestion, I would suggest the appropriate Params
structure. If we were to take the ClientData route, then there are a
number of other fields (e.g. secureClientCommunication) would belong to
ClientData. In any case, it does not matter for the use case at hand, as
long as there is a provision for generic HTTP headers.
Subbu
Rich Thompson wrote:
>
> The broadening of this topics to include non-caching and non-http
> headers helps me significantly. Basically I see three potential answers
> to the underlying question:
>
> 1. Introduce a "transportHeaders" field in ClientData and the various
> response structures. The semantics would be defined such that the
> Consumer would be encouraged to forward transport headers as appropriate
> (e.g. not forwarding those consumed by the Consumer or those reflected
> elsewhere in the protocol). This would support headers flowing from the
> browser to reach the Producer, allow for action/event processing to
> update those headers prior to event/render processing and eventual flow
> back to the browser (and would also work for the straight-through case
> of resource URLs :} ). While defining these in the protocol would
> increase the chance of them reaching the Producers, I see two
> significant problems; 1) The headers would be removed from processing by
> other intermediaries (the target of many headers) and 2) those Consumers
> which start streaming their portion of the response to the browser prior
> to receiving the response from all Portlets would be unable to copy the
> headers returned from gM() to the browser (not sure how big a problem
> this is as such Consumers have to compute caching headers before
> receiving Portlet sourced caching info already).
>
> 2. Add a statement to the spec encouraging Consumer to "appropriately
> copy" received headers. This reflects the Consumers role as an
> intermediary, allows for the potential impact of a protocol change
> between how the request is received from the User and how it is
> forwarded to the Portlet, and leaves the headers in the domain where
> they were defined such that any other intermediary understanding them
> can receive them in the expected manner.
>
> 3. Defer statements related to #2 to a section in the Primer discussing
> the intermediary role of the Consumer.
>
> Rich
>
>
> *Richard Jacob <richard.jacob@de.ibm.com>*
>
> 07/24/2006 09:40 AM
>
>
> To
> Subbu Allamaraju <subbu@bea.com>
> cc
> Rich Thompson/Watson/IBM@IBMUS, wsrp
<wsrp@lists.oasis-open.org>
> Subject
> Re: [wsrp] Public review comments: Caching of resources -
clarification
> needed
>
>
>
>
>
>
>
>
> I tend to agree with Rich,
> this seems really to outline a nice extension for HTTP headers (going
even
> beyond pure caching). And I agree that there is a lot of value of
utilizing
> existing WEB caching infrastructure where possible.
> I would argue for such an extension for the following reasons:
> - the cache control headers should not only apply to gR() but also to
gM()
> - other (HTTP headers) might be also of interest. We have a lot of
> customers seeking for the ability to forward request headers to
> producers...
> - other transport specific information (even non-HTTP) might be of
interest
>
> So a generic "header" framework/extension would fit better here.
>
> Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Technical Lead
> WSRP Standardization
> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
>
>
>
> Subbu Allamaraju
> <subbu@bea.com>
> To
> 07/24/06 03:26 PM Rich Thompson <richt2@us.ibm.com>
> cc
> wsrp <wsrp@lists.oasis-open.org>
> Subject
> Re: [wsrp] Public review comments:
> Caching of resources -
> clarification needed
>
>
>
>
>
>
>
>
>
>
> Rich Thompson wrote:
> >
> > I would agree that Subbu's use case relates to http headers rather
than
> > mime attributes and is much more related to CacheControl than it is to
> > the proposed ResourceContext. The one other consideration I would toss
> > into the discussion is that we have tried to keep the protocol
transport
> > agnostic whenever possible. I'm not sure there are significant
> > advantages to add a transport specific field for this rather than an
> > extension related to fuller support for http caching headers.
>
> Resources are going to be served over some transport protocol, with the
> most common (99%?) being HTTP. We also need to consider scenarios that
> strongly rely on HTTP for caching, ranges etc. One example is a portlet
> serving a large report which would benefit from using range headers.
>
> Two arguments for a generic structure
>
> - Support non-cache related headers
> - Mimic the work done for uploadContext in WSRP 1.0.
>
> Subbu
>
> >
> > Rich
> >
> >
> > *Richard Jacob <richard.jacob@de.ibm.com>*
> >
> > 07/24/2006 08:58 AM
> >
> >
> > To
> > Stefan Hepper <sthepper@hursley.ibm.com>
> > cc
> > wsrp <wsrp@lists.oasis-open.org>
> > Subject
> > Re: [wsrp] Public review comments: Caching of resources -
> clarification
> > needed
> >
> >
> >
> >
> >
> >
> >
> >
> > I would argument that if want to mimic/forward HTTP1.1 cache
directives
> > also via WSRP that these headers should become part of the WSRP cache
> > control structure.
> > Why should the cache directive header only apply to gR() and not gM()?
> > I would also like to note that the consumer most likely will
manipulate
> the
> > headers accoring to its needs. It can't be a simple copying of the
WSRP
> > forwarded headers to the HTTP headers of the overall HTTP response.
> > Why is that? Because the Consumer is providing an aggregated resource
> (the
> > page) to the browser (I agree that most likely not in the gR() case)
and
> > thus other factors might influence the resulting/aggregated cache
header.
> > The easiest example is the expiry header which needs to be computed
from
> > the aggregates on the page, most likely the smallest one will win.
> > The same is true for the no-store/no-cache/private headers and
certainly
> > for the others, too.
> >
> > Mit freundlichen Gruessen / best regards,
> >
> > Richard Jacob
> > ______________________________________________________
> > IBM Lab Boeblingen, Germany
> > Dept.8288, WebSphere Portal Server Development
> > WSRP Technical Lead
> > WSRP Standardization
> > Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> > Email: mailto:richard.jacob@de.ibm.com
> >
> >
> >
> > Stefan Hepper
> > <sthepper@hursley
> > .ibm.com>
To
> > wsrp <wsrp@lists.oasis-open.org>
>
> > 07/24/06 06:15 AM
cc
> >
> >
Subject
> > Re: [wsrp] Public review
comments:
>
> > Caching of resources -
>
> > clarification needed
>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Why is the new struct called mimeAttributes? How is this related to
MIME?
> >
> > Stefan
> >
> > Subbu Allamaraju wrote:
> > > I tried to map possible WSRP resource caching options to HTTP, and
> there
> > > are some gaps to be filled.
> > >
> > > Consider the following parties in a scenario:
> > >
> > > UA <-----> Consumer <------> Producer <-------> Resource
> > >
> > > Of the arrows above, the first and third are done over HTTP.
> > >
> > > Let' say, the resource set a Last-Modified header in response to
the
> > > first request. The producer cannot faithfully transmit this info to
> the
> > > consumer. The Consumer can make up a header with the current time
> (i.e.
> > > Last-Modified header received by the UA is the current consumer
time).
> > >
> > > In a future request, the UA sends an If-Modified-Since header, but
> > > again, the consumer cannot transmit this info to the producer. The
> > > producer will not receive this header, and therefore will fetch and
> > > serve the resource again.
> > >
> > > This is just one scenario. There are several headers that are not
> > > mappable between WSRP resource API and HTTP. The only thing that
can
> be
> > > mapped well are the following:
> > >
> > > ETag -------> validateTag
> > > no-cache ---> no expires and no validateTag
> > > public -----> forAll userScope
> > > private ----> forUser userScope
> > >
> > > There are few key caching header values like "max-age" are useful
for
> > > browser/proxy caching, and certain headers like "no-store"
influence
> > > user experience as well as the way browsers expire responses. For
> > > instance "Cache-control: no-cache" is not the same as
"Cache-Control:
> > > no-cache no-store" and the consumer needs some help from the
protocol
> to
> > > be able to set these headers correctly reflecting the intent of the
> > > producer.
> > >
> > > I propose to add the following field to ResourceParams and
> > > ResourceContext structure (based on Richard's proposal to decouple
> > > getResource input/output from getMarkup input/output).
> > >
> > > [0] NamedString mimeAttributes[]
> > >
> > > This will let the producer and consumer carry the intent of the
> > > portlet/resource and UA respectively.
> > >
> > > Since resources could be large, portlets may like to rely on range
> > > headers as well, and the above proposal addresses such needs.
> > >
> > > Subbu
> > >
> > >
> > > Subbu Allamaraju wrote:
> > >> In WSRP 2.0, it is not clear how a producer/consumer would manage
> > >> caching of resources such that intermediate entities such as
caching
> > >> proxies, and also user agents can participate in HTTP 1.1 style of
> > >> caching.
> > >>
> > >> With the WSRP 1.0 style, the resource originator could set caching
> > >> headers like Etag, and Last-Modified. Intermediaries/user agents
> could
> > >> then cache resources by following these headers, and also
supplying
> > >> If-Modified-Since/If-Not-Modified-Since and Etag headers.
> > >>
> > >> How do these headers map to the input/output of the getResource
> > >> operation? I can see that the Etag header could be mapped to
> > >> validateTag, but what about other caching headers? Who is
responsible
> > >> for generating these headers and how do these headers map to WSRP
> 2.0?
> > >>
> > >> Subbu
> > >>
> _______________________________________________________________________
> > >> Notice: This email message, together with any attachments, may
> contain
> > >> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> > >> entities, that may be confidential, proprietary, copyrighted
> and/or
> > >> legally privileged, and is intended solely for the use of the
> individual
> > >> or entity named in this message. If you are not the intended
> recipient,
> > >> and have received this message in error, please immediately return
> this
> > >> by email and then delete it.
> > >>
> > >>
---------------------------------------------------------------------
> > >> To unsubscribe from this mail list, you must leave the OASIS TC
that
> > >> generates this mail. You may a link to this group and all your
TCs
> in
> > >> OASIS
> > >> at:
> > >>
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> > >
> _______________________________________________________________________
> > > Notice: This email message, together with any attachments, may
> contain
> > > information of BEA Systems, Inc., its subsidiaries and
> affiliated
> > > entities, that may be confidential, proprietary, copyrighted
> and/or
> > > legally privileged, and is intended solely for the use of the
> individual
> > > or entity named in this message. If you are not the intended
> recipient,
> > > and have received this message in error, please immediately return
> this
> > > by email and then delete it.
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC
that
> > > generates this mail. You may a link to this group and all your TCs
in
> > > OASIS
> > > at:
> > >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. You may a link to this group and all your TCs in
> > OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. You may a link to this group and all your TCs in
> OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]