On Sun, 2008-10-26 at 14:22 +0100, sebb wrote: > On 26/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-10-26 at 11:37 +0100, Oleg Kalnichevski wrote: > > > On Sat, 2008-10-25 at 23:55 +0100, sebb wrote: > > > > > > Sebastian, > > > > You were right. It seems the easiest and cleanest fix would be the make > > best-match cookie spec pick up RFC2109 spec for cookies generated from > > 'Set-Cookie' headers. > > > > Agreed, and always use RFC2965 for Set-Cookie2 headers. > > The Set-Cookie header did not have a domain, so there may also be a > problem with the RFC2965 handling of a missing domain (it is optional, > just checked). > > The extracted cookie was set up with the domain "localhost", which of > course does not have the ".local" part attached. Same thing happened > when I used the actual local name for the host. Seems to me that > RFC2965 should add the ".local" suffix if necessary when generating > the missing domain. >
This sounds odd, because that is what it does. I could not reproduce the problem with a test case. Would you be able to put together a junit to reproduce the issue? Oleg > > > > > Oleg > > > > > > > > > Hi Sebastian, > > > > > > Formally speaking RFC2965 superseded RFC2109 and rendered it obsolete. > > > However, RFC2965, probably, _should_ be backward compatible > > > > > > > I've been doing some testing with HttpClient 4.0 beta1, and it is > > > > rejecting cookies of the form: > > > > > > > > Set-Cookie: special="abcd efgh"; Version=1 > > > > > > > > > > This cookie seems to work for me. One with an explicit domain attribute > > > does not: > > > > > > Set-Cookie: special="abcd efgh"; domain="localhost"; Version=1 > > > > > > > > > > when tested against a server on localhost, the error message is: > > > > > > > > Illegal domain attribute: "localhost".Domain of origin: > > "localhost.local" > > > > > > > > This appears to be coming from the RFC2965Spec validation which is > > > > chosen by the BestMatchSpec class. > > > > > > > > Surely only Set-Cookie2: headers should be required to pass the > > > > RFC2965 validation? > > > > > > > > > > Probably you are right, but I would like to revisit the spec to be 100% > > > sure. > > > > > > > It looks like the BestMatchSpec class does not allow for using > > > > RFC2109, which I would expect to be used here. > > > > > > > > > > We could make this configurable. Would that make sense for you? > > > > > > Oleg > > > > > > > > > > I can get round the problem by using an IP address instead of a > > > > un-dotted host name, but it seems to me that the wrong Cookie spec > > > > class is being chosen here. > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
