Re: [wsrp] Public review comments: Caching of resources - clarificationneeded

[Subbu Allamaraju <subbu@bea.com>]

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.