OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


To be honest, I'm really confused.
On the one hand we seem to have decided yesterday to not reopen the spec.
On the other hand we seem to see that some functionality is broken/needs to
be added.
But perhaps we can sort that out today.

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


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             02/15/07 08:54 PM         wsrp <wsrp@lists.oasis-open.org>    
                                                                        cc 
                                                                           
                                                                   Subject 
                                       Re: [wsrp] Client header            
                                       propagation to user-agents          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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]