hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Dever <jsde...@sympatico.ca>
Subject Re: [PATCH]: Cookie management refactored. Proposal
Date Thu, 05 Dec 2002 16:03:27 GMT

NOTE: I had a much longer and more insightful email to send, but Mozilla 
crashed on me just before I was about to send it (serves me right for 
running the spell check).  I only saved part of it, and don't have the 
time to re-create it all.  Sorry.

- not sure I like statemgmt as a package name.  just cookie is more 

One thing that bothers me about httpclient, is the flow from headers -> 
datastructure -> header.  Two things happen here: 1) all headers of one 
type are "compressed" into a single header.  2) the value that is pushed 
back out is the reconstructed form from the internal data structure.  

I think that the assumptions that lead the the above are naive.  

If everyone conformed exactly to the spec, there would be little problem 
with converting to an internal datastructure.  The value could be 
reconstructed exactly.  But there are always variations in the input 
which are allowed but lost after parsing.

I also think that it is better to seperate out multiple header values 
into multiple headers, rather than compressing them all as multiple 
values to a single header.  We save little in overhead, make the headers 
more difficult to parse, ant loose possibly interesting formatting 

 >From a cookie perspective, If the server sends a Set-Cookie with a 
particular value, the server expects to get the exact same value back: 
not the perfectly formatted RFC form, not some other form, the exact 
same value.

One FIXME that has been in the code for a long time illistrates my point:
+            /* FIXME.  We assume here that all the cookies we're 
sending back
+             * are the same version.  A better solution might be to 
+             * cookies of different versions and send them on separate 
+             * headers.
+             */

The BNF for Cookie from rfc2965 requires that only one cookie version 
per Cookie header:

    cookie          =  "Cookie:" cookie-version 1*((";" | ",") cookie-value)

So httpclient MUST allow for more than one Cookie header in order to 
conform to the spec.  At the moment, the one header concept extends very 
deep into httpclient internals steming from the hashtable that keys on 
the header name.  Changing this would have significant consequences, and 
I'm not proposing this change be made for 2.0

But when 2.1 rolls around, these should be some requirements:
- Parsing of headers should preserve the original value.
- Internal representations of headers should only track enough 
information to manage the value.
- The raw header value should be a datamember of the header representation.


Kalnichevski, Oleg wrote:

 >As discussed, the cookie management has been re-worked to allow for 
(more) flexible cookie parsing and validation. Cookie management is now 
policy driven and can be controlled by the HttpClient consumer through 
CookiePolicy class or standards compliance strictness flag . When strict 
mode is set false, HttpMethodBase allies less compliant but more 
generally used cookie validation policy which should make the HttpClient 
compatible with the cookie management of the major browsers out there.
 >The patch retains API compatibility with the older Cookie class (some 
of the methods should later be deprecated, though)
 >All the unit tests *should* be okay
 >Please review the patch design-wise and give me your feedback or critique
 >I'd like to work a bit further on the patch before it is applied 
(provided it gets approved at all) to make stuff RFC 2965 compliant
 >>Oleg Kalnichevski | Senior Consultant | BearingPoint | Zurich, 
 >>Phone +41 43 299 64 49 | Mobile +41 79 653 25 62 | Fax +41 43 299 64 65
 > <<cookie.patch>>
 >To unsubscribe, e-mail:   
 >For additional commands, e-mail: 

View raw message