[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Client header propagation to user-agents
My negative reaction pertains to specifying this as part of 2.0 .
Moving forward we can certainly add this use case and discuss
extensions/means for its support.
-Mike-
Subbu Allamaraju wrote:
> I would like to point out that, decisions like this will bite us back,
> and we need to solve the problems as fully as possible in the
> protocol. Let's take the time to discuss these in detail before
> dropping the ball.
>
> Subbu
>
> Richard Jacob wrote:
>
>> I agree with Mike here.
>> I think we should drop that use case from the spec for now.
>> JSR286 allows cookies to flow from/to the portlet, but client side
>> manipulation of that cookies is not mandated there, too.
>> Is this a new use case you'd like to bring into JSR286?
>>
>> Mit freundlichen Gruessen / best regards,
>>
>> Richard Jacob
>> ______________________________________________________
>> IBM Lab Boeblingen, Germany
>> Dept. 2289, WebSphere Portal Server Development 1
>> WSRP Team Lead
>> WSRP Architecture & Standardization
>> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
>> Email: mailto:richard.jacob@de.ibm.com
>>
>>
>>
>> Michael
>> Freedman
>> <michael.freedman
>>
>> @oracle.com> To
>> wsrp
>> <wsrp@lists.oasis-open.org> 02/15/07 12:17
>> AM cc
>>
>>
>> Subject Re: [wsrp] Client
>> header propagation
>> to user-agents
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Yes, I was looking for something that was viable and would actually work
>> for most/all use cases. Without that I don't see the value in doing
>> this, particularly in spec. As you already require some indication the
>> code knows its running in a portlet environment (because you require the
>> namespace tag) -- how about defining a specific format for the consumer
>> to encode the value field so that clients can extract their original
>> values. Obviously a pain in client side handling being different for
>> the portlet case but at least you avoid the problem of support being
>> called and told there is an intermittent problem where certain fields on
>> the page sometimes act screwy....all because of the variability of
>> consumer cookie caching support.
>> -Mike-
>>
>> Subbu Allamaraju wrote:
>>
>>> The comment parameter is not part of the "Cookie" header. So, when
>>> Consumer receives the cookie, it does not get back the comment.
>>>
>>> Here are the options:
>>>
>>> a. Currently, consumers implement some kind of cookie store to store
>>> init cookies. Those consumers can be extended to store cookie mapping
>>> info for the duration of the consumer's runtime.
>>>
>>> b. Support a persistent cookie-store on the consumer. Consumers in (a)
>>> are most likely ignoring the lifetime semantics of init cookies
>>> anyway, and would benefit from a persistent store.
>>>
>>> Supporting (b) definitely takes some extra work, and consumers can
>>> choose to go with (a) instead.
>>>
>>> Subbu
>>>
>>>
>>> Michael Freedman wrote:
>>>
>>>> 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.
>>>>
>>>>
>>> _______________________________________________________________________
>>> 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]