[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Client header propagation to user-agents
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. >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]