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

[Michael Freedman <michael.freedman@oracle.com>]

Why wouldn't the consumer rewrite the value field of the producer cookie 
to wrap the producer's value along with this mapping data so everything 
is transported in a single cookie?
     -Mike-

Stefan Hepper wrote:

> I think storing the mapping information not with the cookie will also 
> not work as general solution as you need to store them for as long as 
> the cookie lifetime which is quite a hard requirement for some consumers.
>
> Stefan
>
>
> Subbu Allamaraju wrote:
>
>> Good points.
>>
>>  From an implementation point of view, setting a companion cookie is 
>> an option. However, as you point out, there are browser limits on the 
>> number of cookies stored per domain (starting from IE's 20 to Safari's
>> 1000+).
>>
>> Two possible solutions:
>>
>> a. Store the mapping information locally on the consumer
>> b. Require some metadata from the producer on each cookie whether it 
>> needs to be proxied to the browser or not
>>
>> In general, storing mapping info in cookies may not be work out. When 
>> cookie limits are reached, browser will start dropping some cookies, 
>> and the consumer may lose the mapping information forever.
>>
>> Subbu
>>
>>
>> Stefan Hepper wrote:
>>
>>> 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.
>>>>
>>>>
>>>
>>>
>> _______________________________________________________________________
>> 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.
>>
>>
>
>