There is some ambiguity regarding formatting cookies which include both new-style and old-style cookies. I don't think it is appropriate to format cookies differently in the same header. Therefore, if there is an old-style cookie present amongst the cookies to be formatted, I delegate all formatting to RFC2109 spec. But I may be wrong on this, let me know ur suggestions.
On 8/27/05, Michael Becke <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
