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

[Stefan Hepper <sthepper@hursley.ibm.com>]

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
> 
>