hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <o.kalnichev...@dplanet.ch>
Subject [PATCH]: Cookie management refactored
Date Sat, 07 Dec 2002 18:44:32 GMT
After having read through RFC2965 I have come to realize that RFC2965 is
much more than a refined RFC2109. There are over a dozen instances where
things differ quite radically. It makes me believe that RFC2965
compliant specification can inherit almost no code from the RFC2109 one.
Besides, it takes a sub-classing Cookie class to accommodate all the new
properties of the RFC2965 compliant cookie. That's more than a weekend
job, for sure

All this makes me seek your approval to have all the changes I have made
so far folded into CVS source tree first and polished a bit before I can
get down to writing RFC2965 compliant Cookie and CookieSpec classes.
Besides, we may put this work on hold for a while as my time may be
better spent doing something else which is more critical for the coming


- Policy driven cookie management
- Improved Netscape draft compliance
- Full RFC2109 compliance
- Compatibility mode to simulate relaxed cookie management of popular
web browsers
- In strict mode all the cookies are still crammed into one Cookie
header. In non-strict mode, however, each cookie is sent in a separate

Bug fixes:
- Cookie constructor now rejects cookie name containing blanks
- Cookie constructor now not rejects cookie name starting with $ (That's
a bad one)
- Netscape compliant spec now properly formats Cookie header value
(domain and path attributes not included) 
- RFC2109 compliant spec now properly formats Cookie header value
(cookie value and attribute values are quoted) 

Feedback, critique is welcome, as always 



On Thu, 2002-12-05 at 17:03, Jeffrey Dever wrote:
> 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 
> descriptive
> 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 
> information.
>  >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 
> separate
> +             * cookies of different versions and send them on separate 
> cookie
> +             * 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.
> -jsd
> Kalnichevski, Oleg wrote:
>  >Jeff,
>  >
>  >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
>  >
>  >Cheers
>  >
>  >  
>  >
>  >>Oleg Kalnichevski | Senior Consultant | BearingPoint | Zurich, 
> Switzerland
>  >>Phone +41 43 299 64 49 | Mobile +41 79 653 25 62 | Fax +41 43 299 64 65
>  >>www.bearingpoint.com
>  >>    
>  >>
>  > <<cookie.patch>>
>  >  
>  >
>  >-------------------------
>  >
>  >--
>  >To unsubscribe, e-mail:   
> <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
>  >For additional commands, e-mail: 
> <mailto:commons-httpclient-dev-help@jakarta.apache.org>
>  >
> --
> To unsubscribe, e-mail:   <mailto:commons-httpclient-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-httpclient-dev-help@jakarta.apache.org>
Oleg Kalnichevski <o.kalnichevski@dplanet.ch>

View raw message