Client header propagation to user-agents

[Subbu Allamaraju <subbu@bea.com>]

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.