[Dillo-dev]Bug #364
Hello Dilldoers =b Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant? Here is what I received: Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT I'm under the impression the Expires attribute is meant to be as: Wdy, DD-MM-YYYY HH:MM:SS GMT Therefore, because the Weekday isn't in an abbreviated form it is being discarded? Regards, Russell
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Ehrmm, Dillodoers I'd say... :-)
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
Most probably. The timestamp parsing routine in cookies.c accepts: RFC-1123 | RFC-850 | ANSI asctime. Reviewing the SPECS though, it's interesting to note that the date format is not defined with precision inside them, especially the weekday. RFC2109 states it as: Wdy, DD-MM-YYYY HH:MM:SS GMT but it doesn't say whether 'Wdy' is three chars long... Netscape's original SPEC: http://www.danbbs.dk/~erikoest/hello.htm (this page has a quote at the bottom) says: <q> The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes. </q> Nothing about 'Wdy' length. Finally RFC 822 goes into the depth of defining the day format, and it does so as three chars long: <q> day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" </q> A long weekday is understandable as an interpretation of the SPEC (where it isn't defined). Moreover, the above mentioned URL, uses a long weekday as an example: <q> expires=Wednesday, 09-Nov-99 23:12:40 GMT </q> As you see, I'm not sure whether this long day is a SPEC violation or not. I'm more inclined to think it is an acceptable interpretation. Shall you find more evidence, or feel confident enough to modify Cookies_create_timestamp(), it may be included in 0.8.3. Comments, anyone? -- Cheers Jorge.-
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
Could be... This is my second answer because I made some mistakes... AFAIK, the most current RFC for cookies is RFC-2965, but it doesn't say a word about the Expires format. The previous spec, RFC-2109 says: <q> Netscape's original proposal defined an Expires header that took a date value in a fixed-length variant format in place of Max-Age: Wdy, DD-Mon-YY HH:MM:SS GMT </q> Note that YY is using two chars here, and that not a word is said about 'Wdy'. http://www.danbbs.dk/~erikoest/hello.htm makes a real soup of it all: In 1996 it was: <q> Wdy, DD-Mon-YY HH:MM:SS GMT expires=Wednesday, 09-Nov-99 23:12:40 GMT </q> *Note the example uses a full weekday name. In 1997 it became: <q> The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes. </q> Note the four characters year syntax, and the dashes requirement. As for 'Wdy', RFC-1123 refers to RFC-822 which says day is: <q> day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" </q> RFC-1036 (USENET) which obsoletes RFC-850 says dates must be acceptable to RFC-822. For instance: Dates: Wdy, DD Mon YY HH:MM:SS TIMEZONE (that's why the dashes and GMT requirements was added). So that's it. It seems there are four legacy but legal formats: Wdy, DD-Mon-YY HH:MM:SS GMT Wdy, DD-Mon-YYYY HH:MM:SS GMT Weekday, DD-Mon-YY HH:MM:SS GMT Weekday, DD-Mon-YYYY HH:MM:SS GMT with the second one being the most "correct". BTW, the site that Kelson pointed to as an example that uses cookies and locks dillo on a CPU hog, uses: Wdy, DD-Mon-YY HH:MM:SS GMT so it's currently ignored. I'm working on it now, and found this interesting fact while testing http://mosquito.wordpress.org/view_all_bug_page.php. AFAIS, we'll have to accept the four date formats... Does anyone know better? Does anyone Wanna' try to find out? Comments out of simpathetic feelings to a maintainer having a hard time through the RFCs? :) -- Cheers Jorge.-
Hi, I've been thinking a little bit about it, and have some input on the matter. ons 2004-10-20 klockan 18:58 -0300 skrev Jorge Arellano Cid:
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
Could be...
This is my second answer because I made some mistakes...
AFAIK, the most current RFC for cookies is RFC-2965, but it doesn't say a word about the Expires format.
The previous spec, RFC-2109 says:
It should be noted here that this is said in the "historical" section. And that "Expires" never has been part of an RFC (IIRC).
<q> Netscape's original proposal defined an Expires header that took a date value in a fixed-length variant format in place of Max-Age:
Wdy, DD-Mon-YY HH:MM:SS GMT </q>
Note that YY is using two chars here, and that not a word is said about 'Wdy'.
[snip]
So that's it. It seems there are four legacy but legal formats:
Wdy, DD-Mon-YY HH:MM:SS GMT Wdy, DD-Mon-YYYY HH:MM:SS GMT Weekday, DD-Mon-YY HH:MM:SS GMT Weekday, DD-Mon-YYYY HH:MM:SS GMT
with the second one being the most "correct".
I want to point out here that we don't use the weekday part in any way, so it can be discarded. And the year part is parsed with strtol() in a way that it doesn't matter if it's two or four chars long (there is a check right after it to account for both cases).
BTW, the site that Kelson pointed to as an example that uses cookies and locks dillo on a CPU hog, uses:
Wdy, DD-Mon-YY HH:MM:SS GMT
so it's currently ignored.
I'm working on it now, and found this interesting fact while testing http://mosquito.wordpress.org/view_all_bug_page.php.
AFAIS, we'll have to accept the four date formats...
I agree. In a perfect world the "Max-Age" attribute would be used everywhere. However, "Expires" has become a de-facto standard (and a badly defined such) which needs alot of "special attention" but it's also a must to have working cookies.
Does anyone know better?
Not really... :-)
Does anyone Wanna' try to find out? Comments out of simpathetic feelings to a maintainer having a hard time through the RFCs? :)
My advice: don't stare directly at it! ;-) Regards, Jörgen
On Thu, Oct 21, 2004 at 01:26:29AM +0200, Jorgen Viksell wrote:
Hi,
I've been thinking a little bit about it, and have some input on the matter.
ons 2004-10-20 klockan 18:58 -0300 skrev Jorge Arellano Cid:
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
Could be...
This is my second answer because I made some mistakes...
AFAIK, the most current RFC for cookies is RFC-2965, but it doesn't say a word about the Expires format.
The previous spec, RFC-2109 says:
It should be noted here that this is said in the "historical" section. And that "Expires" never has been part of an RFC (IIRC).
FWIW: RFC-2965 says HTTP1.1 must use "Expires" in some conditions, but it doesn't define its syntax. The format is referred to as "old-date" RFC-2109 says the same and mentions a definition of "Expires" in an historical section.
[snip]
So that's it. It seems there are four legacy but legal formats:
Wdy, DD-Mon-YY HH:MM:SS GMT Wdy, DD-Mon-YYYY HH:MM:SS GMT Weekday, DD-Mon-YY HH:MM:SS GMT Weekday, DD-Mon-YYYY HH:MM:SS GMT
with the second one being the most "correct".
I want to point out here that we don't use the weekday part in any way, so it can be discarded. And the year part is parsed with strtol() in a way that it doesn't matter if it's two or four chars long (there is a check right after it to account for both cases).
Not that tolerant, the code _was_ discarding some cookies. I made a patch that accepts the four formats, and added some comments. I'm testing the patch with the one for the CPU-hog Kelson discovered.
BTW, the site that Kelson pointed to as an example that uses cookies and locks dillo on a CPU hog, uses:
Wdy, DD-Mon-YY HH:MM:SS GMT
so it's currently ignored.
I'm working on it now, and found this interesting fact while testing http://mosquito.wordpress.org/view_all_bug_page.php.
Kelson: mosquito's site works on my computer now! :-) Just allow me a couple of hours to test it some more (the new redirection loop code) before commiting to CVS.
AFAIS, we'll have to accept the four date formats...
I agree. In a perfect world the "Max-Age" attribute would be used everywhere. However, "Expires" has become a de-facto standard (and a badly defined such) which needs alot of "special attention" but it's also a must to have working cookies.
As for the SPEC, "Max-Age" is optional... At least now my tree is parsing the whole set.
Does anyone know better?
Not really... :-)
Good! :-) Then my patch will be cheerfully welcomed.
Does anyone Wanna' try to find out? Comments out of simpathetic feelings to a maintainer having a hard time through the RFCs? :)
My advice: don't stare directly at it! ;-)
Not again! :-) -- Cheers Jorge.-
Hello all, Nice research. If you like I'll look into it more before a commitment is made, but from what you've described all four might be the go. I'll search some more tonight. Regards, Russell On Wed, Oct 20, 2004 at 06:58:20PM -0300, Jorge Arellano Cid wrote:
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
Could be...
This is my second answer because I made some mistakes...
AFAIK, the most current RFC for cookies is RFC-2965, but it doesn't say a word about the Expires format.
The previous spec, RFC-2109 says:
<q> Netscape's original proposal defined an Expires header that took a date value in a fixed-length variant format in place of Max-Age:
Wdy, DD-Mon-YY HH:MM:SS GMT </q>
Note that YY is using two chars here, and that not a word is said about 'Wdy'.
http://www.danbbs.dk/~erikoest/hello.htm makes a real soup of it all:
In 1996 it was: <q> Wdy, DD-Mon-YY HH:MM:SS GMT expires=Wednesday, 09-Nov-99 23:12:40 GMT </q>
*Note the example uses a full weekday name.
In 1997 it became:
<q> The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT
This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes. </q>
Note the four characters year syntax, and the dashes requirement.
As for 'Wdy', RFC-1123 refers to RFC-822 which says day is:
<q> day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" </q>
RFC-1036 (USENET) which obsoletes RFC-850 says dates must be acceptable to RFC-822. For instance:
Dates: Wdy, DD Mon YY HH:MM:SS TIMEZONE
(that's why the dashes and GMT requirements was added).
So that's it. It seems there are four legacy but legal formats:
Wdy, DD-Mon-YY HH:MM:SS GMT Wdy, DD-Mon-YYYY HH:MM:SS GMT Weekday, DD-Mon-YY HH:MM:SS GMT Weekday, DD-Mon-YYYY HH:MM:SS GMT
with the second one being the most "correct".
BTW, the site that Kelson pointed to as an example that uses cookies and locks dillo on a CPU hog, uses:
Wdy, DD-Mon-YY HH:MM:SS GMT
so it's currently ignored.
I'm working on it now, and found this interesting fact while testing http://mosquito.wordpress.org/view_all_bug_page.php.
AFAIS, we'll have to accept the four date formats...
Does anyone know better? Does anyone Wanna' try to find out? Comments out of simpathetic feelings to a maintainer having a hard time through the RFCs? :)
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Thu, Oct 21, 2004 at 08:24:20AM +0800, Russell J. Wood wrote:
Hello all,
Nice research. If you like I'll look into it more before a commitment is made, but from what you've described all four might be the go.
I'll search some more tonight.
Well, now my tree (and soon CVS) is doing the four. If you want to dig the RFCs some more, beware it takes a lot of time, and that even when finally a technical matter is perfectly clear, it must be confronted with "de-facto". Soon I'll require some testing if the patch. Advogato is expected to start working... Stay tuned... -- Cheers Jorge.-
On Wed, Oct 20, 2004 at 08:18:20PM +0800, Russell J. Wood wrote:
Hello Dilldoers =b
Would the said bug be because the Set-Cookie entity sent from advogato.org is not RFC compliant?
Here is what I received:
Set-Cookie: id=<data>; path=/; Expires=Thursday, 20-Oct-2005 11:57:18 GMT
I'm under the impression the Expires attribute is meant to be as:
Wdy, DD-MM-YYYY HH:MM:SS GMT
Therefore, because the Weekday isn't in an abbreviated form it is being discarded?
The patch was just commited to CVS! Please test this site and tell us how it works. Hey!, don't forget to check no other dillo instance is holding a lock on the cookie file (run only one to be sure, or check it says "Enabling cookies as from cookiesrc..."). Kelson, Jörgen: This patch also deals with the four formats and other things: * Removed a CPU-hog on 302 redirections with cookies. * Made 302 redirections non-cacheable (incomplete). * Implemented a new scheme for detecting redirection loops. * Fixed cookies to accept four legacy old-date formats for "Expires". So for the mosquitos page (problem with CPU-hog and rejected cookie), it works for me now. http://mosquito.wordpress.org/view_all_bug_page.php Just set: .wordpress.org ACCEPT in cookiesrc ("mosquito.wordpress.org ACCEPT" may also work). Note that when cookies are not allowed from there, a redirection loop is detected! Urbi et Orbi: please test this CVS with any HTTP redirection pages that you can find (not meta refresh). The plan is to make this 0.8.3-rc3 on Friday and to release by Wednesday. Sebastian: I planning to remove the patch for anchors from rc3, that is, unless you consider it safe enough to include it at this stage. -- Cheers Jorge.-
participants (3)
-
Jorge Arellano Cid -
Jorgen Viksell -
Russell J. Wood