[Fwd: Re: [wsrp] Client header propagation to user-agents]

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

sorry, this should have gone to the complete list, I'll never understand 
why the list is not automatically set as reply-to...

Stefan

--- Begin Message ---

• From: Stefan Hepper <sthepper@hursley.ibm.com>
• To: Subbu Allamaraju <subbu@bea.com>
• Date: Tue, 13 Feb 2007 16:29:21 +0100

Hi Subbu,
with requiring that you re-write each cookie and that duplicate each 
cookie on the client as you also require to remember somehow the 
original domain, path, port. Given that the recommendation is to allow 
storing 20 cookies per web server this would mean that only 10 cookies 
per consumer are likely to be supported. Isn't that quite restrictive?
That would only be needed if you really want to access the cookies on 
the client, so maybe it would make sense that the consumer indicates if 
that is really the case or not and thus allow the consumer to make the 
re-writing accordingly. Also the namespacing is only needed for the 
client access use case.

Stefan

Subbu Allamaraju wrote:
> During last week's interfaces call, I was asked to outline a proposal to 
>  extend header propagation all the way to the user agent. This is in 
> addition to the proposal submitted by Rich last week to transport such 
> headers within the protocol.
> 
> Here is a quick summary of the text below.
> 
> The Set-Cookie/Set-Cookie2 headers can contain "name", "value", 
> "comment", "domain", "max-age", "pat", secure", "version", "discard", 
> and "port" attributes.
> 
> The proposal is to require the Producer to use the namespacePrefix for 
> generating the cookie name, and require the Consumer to rewrite the 
> "domain", "path", and "port" parameters.
> 
> (The "port" parameter is introduced RFC 2965 as part of the Set-Cookie2 
> header. This is not widely used.)
> 
> The net benefits of this proposal are:
> 
> - Portlets can write script to access state contained in cookies. This 
> opens up the door to support more web applications over WSRP.
> 
> - Consumers can use browsers as a cookie store instead of managing 
> cookies locally.
> 
> Please comment on before the next TC/Interfaces calls.
> 
> Subbu
> 
> -----------------------------------------------------------------------
> 
> Section 6.1.16 MimeResponse
> ---------------------------
> 
> The following rules apply to cookies returned by the Producer via the 
> clientHeaders structure with a name of Set-Cookie or Set-Cookie2. Such 
> clientHeaders correspond to the Set-Cookie and Set-Cookie2 headers 
> specified by RFC 2109 and RFC 2965, and the values of such headers MUST 
> follow RFC 2109 or 2965 for all cookie parameters.
> 
> The Producer MUST prefix the names of cookies with the namespacePrefix 
> supplied by the Consumer. When a cookie includes any of domain, path, or 
> port parameters, the Producer MUST ensure that their values correspond 
> to any domain, path or port that it expects the Consumer to submit 
> future requests to. Consumers may ignore cookies whose names and 
> parameters do not follow these statements, as such cookies may conflict 
> with other cookies managed by the Consumer.
> 
> When a Consumer receives a clientHeaders element with a name of 
> Set-Cookie or Set-Cookie2, it SHOULD return HTTP headers named 
> Set-Cookie or Set-Cookie2 to the user-agent subjected to its 
> security-policy restrictions in addition to those rules specified by 
> RFCs 2109 and 2965. If the received cookie includes any of domain, path 
> or port parameters, the Consumer MUST replace those with corresponding 
> values for the Consumer such that those values remain valid for the 
> user-agent receiving the cookies. The Consumer MUST use the 
> Producer-supplied values for other parameters.
> 
> If the names of clientHeaders received by a Consumer correspond to any 
> caching response headers specified in RFC 2616, the Consumer MUST 
> interpret those headers as guidance related to caching the markup or 
> resource provided by the Producer. The Consumer MAY propagate such 
> headers to the user-agent subjected to its own caching policies.
> 
> Note that some Consumer implementations may prohibit transporting 
> clientHeaders received during the markup generation phase to user 
> agents. Portlets counting on user-agents receiving such headers must 
> program themselves to account for this behavior.
> 
> 
> Section 6.1.10 ClientData
> -------------------------
> 
> When a Consumer receives Cookie or Cookie2 headers from the user-agent 
> corresponding to cookies previously returned by the Producer via the 
> clientHeaders structure, the Consumer SHOULD include clientHeaders named 
> Cookie or Cookie2 in requests to the Producer subjected to its 
> security-policy restrictions in addition to those rules specified by 
> RFCs 2109 and 2965. If the request from the user-agent corresponds to 
> serve a resource via HTTP, the Consumer SHOULD include corresponding 
> HTTP headers named Cookie or Cookie2 subjected to the same policy. If 
> the Consumer rewrote the domain, path, or port parameters, the Consumer 
> MUST replace those values with those originally supplied by the Producer 
> while generating the values.
> 
> When a Consumer receives caching related request headers, it MAY 
> propagate such headers to the Producer either via the clientHeaders 
> structure (for those operations that return markup) or as HTTP request 
> headers for resource generating requests over HTTP.
> 
> 
> 
> _______________________________________________________________________
> 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.
> 
> 

--- End Message ---