Re: BestMatchSpec - why does it not choose RFC2109?
> This is using > > httpclient-4.0-beta1.jar > httpcore-4.0-beta3.jar > > Login form get: localhost abcd=efgh > == > [DEBUG] wire - >> "POST /examples/servlets/servlet/CookieExample > HTTP/1.1[EOL]" > [DEBUG] wire - >> "Content-Length: 42[EOL]" > [DEBUG] wire - >> "Content-Type: application/x-www-form-urlencoded[EOL]" > [DEBUG] wire - >> "Host: localhost:8080[EOL]" > [DEBUG] wire - >> "Connection: Keep-Alive[EOL]" > [DEBUG] wire - >> "User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)[EOL]" > [DEBUG] wire - >> "Expect: 100-Continue[EOL]" > [DEBUG] wire - >> "[EOL]" > [DEBUG] wire - << "HTTP/1.1 100 Continue[EOL]" > [DEBUG] wire - >> "cookiename=special&cookievalue=abcd%3Defgh" > [DEBUG] wire - << "HTTP/1.1 200 OK[EOL]" > [DEBUG] wire - << "Server: Apache-Coyote/1.1[EOL]" > [DEBUG] wire - << "Set-Cookie: special="abcd=efgh"; Version=1[EOL]" > [DEBUG] wire - << "Content-Type: text/html[EOL]" > [DEBUG] wire - << "Content-Length: 742[EOL]" > [DEBUG] wire - << "Date: Sun, 26 Oct 2008 20:25:27 GMT[EOL]" > [WARN] ResponseProcessCookies - Cookie rejected: "[version: 1][name: > special][value: abcd=efgh][domain: localhost][path: > /examples/servlets/servlet][expiry: null]". Illegal domain attribute: > "localhost".Domain of origin: "localhost.local" Sebastian I managed to reproduce the problem and am working on a fix. Thank you Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BestMatchSpec - why does it not choose RFC2109?
On 26/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > On Sun, 2008-10-26 at 15:49 +0100, sebb wrote: > > On 26/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > 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? > > > > > > > I'll have a go later. > > > > What I used was the Tomcat Cookie Example running locally combined > > with a modified ClientFormLogin example from HC SVN, but that's > > overkill for a test case. > > > > Examples that failed are as follows: > > > > Set-Cookie: special="abcd=efgh"; Version=1 > > Set-Cookie: special="abcd efgh"; Version=1 > > > > Ones that worked OK are: > > > > Set-Cookie: special=abcdefgh > > <"abcd efgh"> Set-Cookie: special="abcd efgh" > > > > It's the ones that have a "Version" attribute that fail for me. > > > > Note: the <> above are used to enclose the "cookievalue" parameter I > > used in the CookieExample form. > > > > > Sebastian, > > Bizarre. Could you please post a wire log / context log of that session? > This may be enough for me to figure out the cause of the problem. > This is using httpclient-4.0-beta1.jar httpcore-4.0-beta3.jar Login form get: localhost abcd=efgh == [DEBUG] wire - >> "POST /examples/servlets/servlet/CookieExample HTTP/1.1[EOL]" [DEBUG] wire - >> "Content-Length: 42[EOL]" [DEBUG] wire - >> "Content-Type: application/x-www-form-urlencoded[EOL]" [DEBUG] wire - >> "Host: localhost:8080[EOL]" [DEBUG] wire - >> "Connection: Keep-Alive[EOL]" [DEBUG] wire - >> "User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)[EOL]" [DEBUG] wire - >> "Expect: 100-Continue[EOL]" [DEBUG] wire - >> "[EOL]" [DEBUG] wire - << "HTTP/1.1 100 Continue[EOL]" [DEBUG] wire - >> "cookiename=special&cookievalue=abcd%3Defgh" [DEBUG] wire - << "HTTP/1.1 200 OK[EOL]" [DEBUG] wire - << "Server: Apache-Coyote/1.1[EOL]" [DEBUG] wire - << "Set-Cookie: special="abcd=efgh"; Version=1[EOL]" [DEBUG] wire - << "Content-Type: text/html[EOL]" [DEBUG] wire - << "Content-Length: 742[EOL]" [DEBUG] wire - << "Date: Sun, 26 Oct 2008 20:25:27 GMT[EOL]" [WARN] ResponseProcessCookies - Cookie rejected: "[version: 1][name: special][value: abcd=efgh][domain: localhost][path: /examples/servlets/servlet][expiry: null]". Illegal domain attribute: "localhost".Domain of origin: "localhost.local" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "Cookies Example[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "Cookies Example[\r][\n]" [DEBUG] wire - << "Your browser isn't sending any cookies[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "You just sent the following cookie to your browser:[\r][\n]" [DEBUG] wire - << "Name: specialValue: abcd=efgh[\r][\n]" [DEBUG] wire - << "Create a cookie to send to your browser[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "Name: [\r][\n]" [DEBUG] wire - << "Value: [\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" [DEBUG] wire - << "[\r][\n]" Login form get: localhost abcd efgh == [DEBUG] wire - >> "POST /examples/servlets/servlet/CookieExample HTTP/1.1[EOL]" [DEBUG] wire - >> "Content-Length: 40[EOL]" [DEBUG] wire - >> "Content-Type: application/x-www-form-urlencoded[EOL]" [DEBUG] wire - >> "Host: localhost:8080[EOL]" [DEBUG] wire - >> "Connection: Keep-Alive[EOL]" [DEBUG] wire - >> "User-Agent: Apache-HttpClient/4.0-beta1 (java 1.4)[EOL]" [DEBUG] wire - >> "Expect: 100-Continue[EOL]" [DEBUG] wire - >> "[EOL]" [DEBUG] w
Re: BestMatchSpec - why does it not choose RFC2109?
On Sun, 2008-10-26 at 15:49 +0100, sebb wrote: > On 26/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > 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? > > > > I'll have a go later. > > What I used was the Tomcat Cookie Example running locally combined > with a modified ClientFormLogin example from HC SVN, but that's > overkill for a test case. > > Examples that failed are as follows: > > Set-Cookie: special="abcd=efgh"; Version=1 > Set-Cookie: special="abcd efgh"; Version=1 > > Ones that worked OK are: > > Set-Cookie: special=abcdefgh > <"abcd efgh"> Set-Cookie: special="abcd efgh" > > It's the ones that have a "Version" attribute that fail for me. > > Note: the <> above are used to enclose the "cookievalue" parameter I > used in the CookieExample form. > Sebastian, Bizarre. Could you please post a wire log / context log of that session? This may be enough for me to figure out the cause of the problem. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BestMatchSpec - why does it not choose RFC2109?
On 26/10/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > 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? > I'll have a go later. What I used was the Tomcat Cookie Example running locally combined with a modified ClientFormLogin example from HC SVN, but that's overkill for a test case. Examples that failed are as follows: Set-Cookie: special="abcd=efgh"; Version=1 Set-Cookie: special="abcd efgh"; Version=1 Ones that worked OK are: Set-Cookie: special=abcdefgh <"abcd efgh"> Set-Cookie: special="abcd efgh" It's the ones that have a "Version" attribute that fail for me. Note: the <> above are used to enclose the "cookievalue" parameter I used in the CookieExample form. > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BestMatchSpec - why does it not choose RFC2109?
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]
Re: BestMatchSpec - why does it not choose RFC2109?
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. > > 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]
Re: BestMatchSpec - why does it not choose RFC2109?
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. 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]
Re: BestMatchSpec - why does it not choose RFC2109?
On Sat, 2008-10-25 at 23:55 +0100, sebb wrote: 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]
