OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


But haven't we made a similar provision for upload data where the 
structure had to make room for protocol-specific headers?

Subbu

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]