The implementation of the RFC2965 spec itself appears to be fine, at least as a whole. The only big problem I see is with the integration into the rest of the code and compatibility with other cookie specs. I also agree with Oleg's comments. getCookieVersion() does not seem necessary, perhaps a CookieSpec2 interface would be better? Cookie2 instead of changing Cookie also sounds good to me.
In particular there are some issues with section 9 of the RFC. Currently there is no way to support just Set-Cookie2 and only RFC2109 can be used in conjunction with Set-Cookie2. In addition the use of the Cookie2 header in the request does not appear to be correct by my reading. I also have some questions about what we should do when sending cookies as a single header and when there are old and new cookie to be sent. There are also some smaller things I noticed: - HttpMethodBase.buildCookie2RequestHeader() has default access which does not seem necessary. - There are a few System.out.println()s - The static vars added to Header and Cookie should be moved to HttpConstants and RFC2965Spec respectively. Mike On 8/26/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > Samit, > > These are my first impressions about the overall design. All my > suggestions are primarily intended to minimize the impact on the > existing API. They are not necessarily the best ideas from the design > perspective. However, since we are redesigning 3.0 API anyway, I > personally do not see a big problem with that. > > (1) We should not change the CookieSpec interface. I am not entirely > sure CookieSpec#getCookieVersion() is necessary at all. I think the > CookiePolicy class can be used instead to achieve the same net result. A > method of the CookiePolicy class that returns a cookie spec given the > cookie version may well do the job > > (2) Cookie class changed to include RFC2965 specific attributes. I would > rather extend Cookie class and put all RFC2965 specific attributes into > a Cookie2 class, if that is feasible. > > (3) We have 39 failing test cases > > Test cases breakage must be fixed before the deadline. Other stuff is > subjective and thus can be addressed past Sept 1st, provided you agree > with my points > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
