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.
