[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 would prefer option 2. When thinking about this it seems that there is another hole in the current spec. How can a portlet provide something for the markup head section (e.g. meta tags for search engines or the title of the page)? This is something our customers has often asked for and I think it would be of value for the gM but a requirement for gR. I'll write a new public review comment for this. Stefan 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]