Opera 6.0: cookie2 & rfc2965 (bug?)
Dario
I'm not able to login to my web-email-service at http://www.umail.it.
It always answers that my browsers do not use cookies.
Obviously this is false. In my Opera preferences I set
1. Enable cookies
2. Automatically accept all cookies
3. Accept from all servers
In IE5.5 all works well (I log into http://www.umail.it)
so I debugged the HTTP connection
a. between Opera 6.0 and the web server
b. between IE5.5 and the same web server
using Proxomitron 4.0.
Comparing the log of the two connections I discovered that Opera
start to send <<Cookie2: $Version="1">> HTTP header-lines to the server
even if the server does not previuosly send a <<Set-Cookie2>> To Opera.
This is a fragment of the Opera connection (not working):
+++RESP 189+++
HTTP/1.0 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 06 Dec 2001 17:09:29 GMT
Content-Type: text/html
Set-Cookie: tinccservizio1=
658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb0fe5f54d6a1907da7661ecea32a3ee9c
30c171010d8b806c88269341461bafa46eac3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c1eccb24d586; domain=www.umail.it; path=/
Set-Cookie: tincctoken=escia%40tin%2Eit%257C0042947370445143; domain=.umail.it; path=/
X-Cache: MISS from proxy.list.it
Proxy-Connection: close
<start> 189: Kill pop-up windows
<start> 189: Suppress all JavaScript errors
<start> 189: Stop browser window resizing
<end> 189: Restore pop-ups after a page loads
+++CLOSE 189+++
+++GET 190+++
Using Proxy - 194.91.195.33:8080
GET http://www.umail.it/Asp/menu.asp?stato=LDAP_ON HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 4.0; U) Opera 6.0 [en]
Host: www.umail.it
Accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
Accept-Language: en
Accept-Charset: windows-1252;q=1.0, utf-8;q=1.0, utf-16;q=1.0, iso-8859-1;q=0.6, *;q=0.1
Accept-Encoding: deflate, gzip
Referer: http://www.umail.it/Asp/menu.asp?stato=LDAP_ON
Cookie: tinccservizio1=
658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb0fe5f54d6a1907da7661ecea32a3ee9c
30c171010d8b806c88269341461bafa46eac3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c1eccb24d586
Cookie2: $Version="1"
Connection: keep-alive
This is a fragment of the IE connection (working well):
+++RESP 263+++
HTTP/1.0 200 OK
Server: Microsoft-IIS/4.0
Date: Thu, 06 Dec 2001 17:12:58 GMT
Content-Type: text/html
Set-Cookie: tinccservizio1=
658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb0fe5f54d6a1907da7661ecea32a3ee9c
30c171010d8b806c88269341461bafa46eac3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c1eccb24d586; domain=www.umail.it; path=/
Set-Cookie: tincctoken=escia%40tin%2Eit%257C8758214317644408; domain=.umail.it; path=/
X-Cache: MISS from proxy.list.it
Proxy-Connection: close
<start> 263: Kill pop-up windows
<start> 263: Suppress all JavaScript errors
<start> 263: Stop browser window resizing
<end> 263: Restore pop-ups after a page loads
+++CLOSE 263+++
+++GET 264+++
Using Proxy - 194.91.195.33:8080
POST http://server-it.imrworldwide.com/cgi-bin/demorecord HTTP/1.0
Accept-Language: en
Content-Type: application/x-www-form-urlencoded
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Win32)
Host: server-it.imrworldwide.com
Content-Length: 160
Pragma: no-cache
Cookie: IMRID=O9gTStTvFaQAAA43ud8
Connection: keep-alive
Accept-encoding: deflate, gzip
+++GET 265+++
Using Proxy - 194.91.195.33:8080
GET http://www.umail.it/Asp/menu.asp?stato=LDAP_ON HTTP/1.0
Accept: application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Referer: http://www.umail.it/Asp/menu.asp?stato=LDAP_ON
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461)
Host: www.umail.it
Cookie: tinccservizio1=
658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb0fe5f54d6a1907da7661ecea32a3ee9c
30c171010d8b806c88269341461bafa46eac3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c1eccb24d586; tincctoken=escia%40tin%2Eit%
257C8758214317644408
Connection: keep-alive
Accept-encoding: deflate, gzip
Why Opera begins to send Cookie2 answers?
Someone in Opera (or outside Opera) can confirm this behaviour?
I read the Cookie2 specification of rfc2965 in http://www.ietf.org/rfc/rfc2965.txt
Thanks for the help
-- Dario
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
>Using Proxomitron 4.0 I think I discovered a bug in Opera 6.0 final.
>
>Comparing the log of the two connections I discovered that Opera
>start to send <<Cookie2: $Version="1">> HTTP header-lines to the server
>even if the server does not previuosly send a <<Set-Cookie2>> To Opera.
My original interpretation of what became sec 3.3.5 in RFC 2965 was
that any "$Version" attribute different from what Opera supported
should cause Opera to send "Cookie2" header. "Set-Cookie"'s implicit
"$Version" is zero (0) .
Rereading the section right now, I can see an alternative
interpretation, that this should only be done if "$Version" >= 1.
Anyway, I do not think this is a serious problem that warrants any
action. After all, servers and clients are supposed to ignore headers
they do not understand.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yn...@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 51 Fax: +47 24 16 40 01
********************************************************************
Dario Dariol
> On Fri, 07 Dec 2001 10:08:35 GMT, Dario <NoS...@NoSPAM.org> wrote:
>
> >Using Proxomitron 4.0 I think I discovered a bug in Opera 6.0 final.
> >
> >Comparing the log of the two connections I discovered that Opera
> >start to send <<Cookie2: $Version="1">> HTTP header-lines to the server
> >even if the server does not previuosly send a <<Set-Cookie2>> To Opera.
>
> My original interpretation of what became sec 3.3.5 in RFC 2965 was
> that any "$Version" attribute different from what Opera supported
> should cause Opera to send "Cookie2" header. "Set-Cookie"'s implicit
> "$Version" is zero (0) .
>
> Rereading the section right now, I can see an alternative
> interpretation, that this should only be done if "$Version" >= 1.
>
> Anyway, I do not think this is a serious problem that warrants any
> action. After all, servers and clients are supposed to ignore headers
> they do not understand.
I re-read the specification and... I agree also.
Sorry for the post.
I'm concerned with the fact that I'm no more able
to login to my Web-Email http://www.umail.it in Opera 6.0
(it was OK in Opera 5.12 and IE 5.5) and I do not understand why.
I used Proxomitron to change my identity (user-agent, navigator.appname,
etc...) in both Opera and IE but IE continues to work but Opera not.
Argh!!!!
Bye
-- Dario
Josef W. Segur
The significant difference is in the cookies Opera and IE send with
the next request:
Opera sends:
Cookie: tinccservizio1=658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818
e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb
0fe5f54d6a1907da7661ecea32a3ee9c30c171010d8b806c88269341461bafa46ea
c3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c
1eccb24d586
IE sends:
Cookie: tinccservizio1=658fab8bd9a3b60285ef98dd5fe42eeec677d1c2d818
e3a90f1917d93a5f7be25609eb42b46cc940c37ccb76b2b9b96e34dd26bfa8d90cb
0fe5f54d6a1907da7661ecea32a3ee9c30c171010d8b806c88269341461bafa46ea
c3b23354f2a50253488e95c3e09fc09da188a326b29c164e56b6ca8f3ccea85113c
1eccb24d586; tincctoken=escia%40tin%2Eit%257C8758214317644408
What has happened is the server sent two Set-Cookie: headers and
Opera missed the second one.
Did you have Opera set to 'Display received cookies' when doing
that part of the test?
--
Joe
Yngve Nysaeter Pettersen (Developer, Opera Software A/S)
<jse...@westelcom.com> wrote:
>What has happened is the server sent two Set-Cookie: headers and
>Opera missed the second one.
That one is a bit subtle, but essentially the cookie is refused
because it is set for the domain ".umail.it".
Because this domain is not part of the ".com,.org,.net" etc. generic
domains Opera perform a DNS lookup for "umail.it" [1], before
accepting it. "umail.it" does not exist, and the cookie is therefore
discarded as an "illegal domain" cookie.
The reason for this is to prevent "villain.co.uk" [2] from setting a
cookie for ".co.uk", while still allowing "login.my.domain.co.uk" [3]
to set a cookie for ".domain.co.uk", provided that an IP address
exists for "domain.co.uk".
According to the original Netscape cookie definition [3] is legal, and
[1] and [2] are both illegal, while it is the other way around
according to RFC 2965 (the new cookie standard, and the RFC 2109, the
previous one).
To get out of the dilemma this caused (while avoiding the "cookie
monster bug") we introduced the DNS verification after some large
national domain sites turned out to have problems with our old way of
enforcing the rules.
This method still requires the webmaster to register an IP address in
the DNS system for his domain.
Tollef Fog Heen
Hash: SHA1
* (Yngve Nysaeter Pettersen (Developer, Opera Software A/S))
| This method still requires the webmaster to register an IP address in
| the DNS system for his domain.
Wouldn't it be more useful if it checked wheter either an A record or
an MX record is present? This won't break as many sites, I imagine,
and neither co.uk., com. nor no. has any MX record (nor should it ever
have).
- --
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Please see my GPG key at http://www.opera.com/~tfheen/gpgkey.asc
iD8DBQE8FdClPd99q+b5XkYRAsLpAJ0aiP/TUK0/jNv8meVfJM0C8UZoLwCggBSU
lNtp/dGdic9qojbYGyGG3FE=
=OEB+
-----END PGP SIGNATURE-----