[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Client header propagation to user-agents
Well then maybe the Comment field? Subbu Allamaraju wrote: > Because, the value needs to be preserved if we want to allow > client-side access. > > Subbu > > Michael Freedman wrote: > >> 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. >>>> >>>> >>> >>> > _______________________________________________________________________ > 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]