Subject: [http-state] Date parsing (was Re: consensus call: cookie server conformance)

From: Adam Barth <[email-masked]>
Date: Sat, 29 Jan 2011 13:54:22 -0800

On Sat, Jan 29, 2011 at 1:51 PM, Daniel Stenberg <[email-masked]> wrote:
> On Sat, 29 Jan 2011, Bjoern Hoehrmann wrote:
>> replacing, say, the date parsing algorithm that's been made up on the
>> spot, and not doing what is proposed here, namely describing the proto- col
>> in a manner that is inconsistent with the vast majority of servers.
>
> I read the date parser algorithm as describing a parser with a set of
> capabilities that a date parser for cookies should have. It doesn't say that
> the parser has to work exactly like that.
>
> I consider "my" date parser compliant, but it parses the string in a
> different way than described in the spec.

When you say "in a different way", do you mean via a different
algorithm or that your implementation outputs different dates for some
input strings?

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 29 Jan 2011 23:08:01 +0100 (CET)

On Sat, 29 Jan 2011, Adam Barth wrote:

> When you say "in a different way", do you mean via a different algorithm or 
> that your implementation outputs different dates for some input strings?

I mean that it uses a different algorithm but ends up with the same output for 
most strings and certainly for all strings using sensible formats.

For really crazy inputs the output may differ a bit, like for example my 
parser is less forgiving on rubbish in the middle of the string as in "Thu, 
999999999999-Aug-2007 20:49:07 GMT" or "Sat, 15-Apr-17 boink:z 21:01:22".

-- 

  / daniel.haxx.se

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 31 Jan 2011 11:38:40 +0100

On Sat, 29 Jan 2011 23:08:01 +0100, Daniel Stenberg <[email-masked]> wrote:
> I mean that it uses a different algorithm but ends up with the same  
> output for most strings and certainly for all strings using sensible  
> formats.
>
> parser is less forgiving on rubbish in the middle of the string as in  
> "Thu, 999999999999-Aug-2007 20:49:07 GMT" or "Sat, 15-Apr-17 boink:z  
> 21:01:22".

That would mean it is not compliant.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 31 Jan 2011 11:42:14 +0100 (CET)

> That would mean it is not compliant.

Sorry, can you please point out what section that says so?

-- 

  / daniel.haxx.se

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 31 Jan 2011 12:01:59 +0100

On Mon, 31 Jan 2011 11:42:14 +0100, Daniel Stenberg <[email-masked]> wrote:
>>> For really crazy inputs the output may differ a bit, like for example  
>>> my parser is less forgiving on rubbish in the middle of the string as  
>>> in "Thu, 999999999999-Aug-2007 20:49:07 GMT" or "Sat, 15-Apr-17  
>>> boink:z 21:01:22".
>>

5.1.1 (in combination with 2.1) says so.

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 31 Jan 2011 12:59:57 +0100 (CET)

> 5.1.1 (in combination with 2.1) says so.

That's not my interpretation at all. I can't find any mention of the algorithm 
having to skip "rubbish" in the date field and continue parsing on after it.

Or what did you mean with not compliant? For the above two examples, what 
would you claim the spec says the algorithm should do?

-- 

  / daniel.haxx.se

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 31 Jan 2011 14:18:41 +0100

On Mon, 31 Jan 2011 12:59:57 +0100, Daniel Stenberg <[email-masked]> wrote:
> That's not my interpretation at all. I can't find any mention of the  
> algorithm having to skip "rubbish" in the date field and continue  
> parsing on after it.
>
> Or what did you mean with not compliant? For the above two examples,  
> what would you claim the spec says the algorithm should do?

As far as I can tell in case of rubbish parsing fails and the algorithm  
therefore fails. It is a little unclear though. If it is supposed to be  
undefined it would be better if that were explicitly stated I think.

---

From: Dan Winship <[email-masked]>
Date: Mon, 31 Jan 2011 08:59:33 -0500

> algorithm having to skip "rubbish" in the date field and continue

"The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date." If you reject some dates that the
5.1.1 algorithm would accept, then your algorithm is not equivalent.

(Likewise if you accept some strings that the 5.1.1 algorithm rejects,
or interpret any accepted string as referring to a different date than
the 5.1.1 algorithm does.)

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 31 Jan 2011 15:03:13 +0100 (CET)

On Mon, 31 Jan 2011, Dan Winship wrote:

> "The user agent MUST use an algorithm equivalent to the following algorithm 
> to parse a cookie-date." If you reject some dates that the 5.1.1 algorithm 
> would accept, then your algorithm is not equivalent.

Right, and I realize I have myself to blame for expressing myself sloppy in my 
first statement, but I was actually comparing my parser's strictness to a few 
browsers' parsers that I know are more liberal in what they parse than what 
the current spec say.

You can all stop pointing fingers now. I'll deal with my parser's compliance, 
and you can deal with yours.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Mon, 31 Jan 2011 09:05:42 -0500

On 01/31/2011 09:03 AM, Daniel Stenberg wrote:
> You can all stop pointing fingers now. I'll deal with my parser's
> compliance, and you can deal with yours.

I was just pointing out what the spec says. At the moment, I have no
plans to "fix" my date parser to conform (though I'm not ruling it out
either).

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 31 Jan 2011 15:09:47 +0100 (CET)

On Mon, 31 Jan 2011, Dan Winship wrote:

> At the moment, I have no plans to "fix" my date parser to conform (though 
> I'm not ruling it out either).

Does this mean your parser is better (than the spec) in some aspects that you 
think are necesary?

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Mon, 31 Jan 2011 10:00:22 -0500

On 01/31/2011 09:09 AM, Daniel Stenberg wrote:
>> At the moment, I have no plans to "fix" my date parser to conform
>> (though I'm not ruling it out either).
> 
> Does this mean your parser is better (than the spec) in some aspects
> that you think are necesary?

No, it's definitely "worse". (It makes no attempt to parse dates whose
fields aren't in one of the standard orders, for instance.) I just don't
think that the "improvement" involved in changing exactly which subset
of the long tail of insanely-wrong Expires attributes I accept is worth
the time it would take to write the code, particularly given that (a)
other implementations are not consistent anyway, and (b) the price of
failure is just "the cookie is expired at the end of the session", not
"the cookie is rejected entirely".

-- Dan