Subject: [http-state] algorithm definitions

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jul 2010 15:42:27 +0200

Hi,

from 
<http://tools.ietf.org/html/draft-ietf-httpstate-cookie-09#section-5.2>:

    A user agent MUST use an algorithm equivalent to the following
    algorithm to parse set-cookie-strings:

    1.  If the set-cookie-string contains a U+003B (";") character:

           The name-value-pair string consists of the characters up to,
           but not including, the first U+003B (";"), and the unparsed-
           attributes consist of the remainder of the set-cookie-string
           (including the U+003B (";") in question).

        Otherwise:

           The name-value-pair string consists of all the characters
           contained in the set-cookie-string, and the unparsed-
           attributes is the empty string.

    2.  If the name-value-pair string lacks a U+003D ("=") character,
        ignore the set-cookie-string entirely.

    3.  The (possibly empty) name string consists of the characters up
        to, but not including, the first U+003D ("=") character, and the
        (possibly empty) value string consists of the characters after
        the first U+003D ("=") character.

    4.  Remove any leading or trailing WSP characters from the name
        string and the value string.

    5.  If the name string is empty, ignore the set-cookie-string
        entirely.

    6.  The cookie-name is the name string, and the cookie-value is the
        value string.

    The user agent MUST use an algorithm equivalent to the following
    algorithm to parse the unparsed-attributes:

    1.  If the unparsed-attributes string is empty, skip the rest of
        these steps.

    2.  Discard the first character of the unparsed-attributes (which
        will be a U+003B (";") character).

    3.  If the remaining unparsed-attributes contains a U+003B (";")
        character:

           Consume the characters of the unparsed-attributes up to, but
           not including, the first U+003B (";") character.

        Otherwise:

           Consume the remainder of the unparsed-attributes.

        Let the cookie-av string be the characters consumed in this step.

    4.  If the cookie-av string contains a U+003D ("=") character:

           The (possibly empty) attribute-name string consists of the
           characters up to, but not including, the first U+003D ("=")
           character, and the (possibly empty) attribute-value string
           consists of the characters after the first U+003D ("=")
           character.

        Otherwise:

           The attribute-name string consists of the entire cookie-av
           string, and the attribute-value string is empty.

    5.  Remove any leading or trailing WSP characters from the attribute-
        name string and the attribute-value string.

    6.  Process the attribute-name and attribute-value according to the
        requirements in the following subsections.  (Notice that
        attributes with unrecognized attribute-names are ignored.)

    7.  Return to Step 1.

Wow -- all of this to say that a string should be tokenized where ";" 
occurs, that the first token and the remaining tokens have different 
roles, and how to parse the individual tokens.

A few ideas how to compress this:

- If part 2 / step 1 removes the leading semicolon, why include it in 
the first place?

- Maybe just say ";" and "=" after stating the Unicode code point once? 
Speaking of which, is *anybody* confused about what these characters 
might be?

- Instead of expressing a for-loop in prose, simply state that the 
string is to be split on semicolons, and a certain set of steps is to be 
applied to each fragment.

Etc.

I've heard that this part is exclusively for those who actually write 
the parsing code, and nobody else need to care. I disagree with that. If 
the spec makes normative requirements on handling non-conforming input, 
then it should be phrased in a way so that it's clear what gets 
processed how.

Giving an example of a conforming algorithm is fine, but substituting 
the description with that algorithm IMHO is not.

For instance, when I debug an HTTP/cookie problem and look at an HTTP 
trace, I want to be able to understand how the recipient is going to 
parse the string. Reading the algorithm really isn't very helpful for that.

Also, if we need algorithms instead of format descriptions, why is it ok 
to define date parsing using an ABNF (see section 5.1.1)?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 16 Jul 2010 17:50:33 +0200

>to define date parsing using an ABNF (see section 5.1.1)?

There is no need for an algorithm, for instance, "parsing unparsed
attributes" is just greedily matching against e.g. (using XML's EBNF)

  attributes ::= (';' s* av-name s* '='? s* av-value s*)*
  av-name    ::= [^=;]* ([^=;] - s) | ''
  av-value   ::= [^;]* ([^;] - s) | ''

For the initial key-value-pair the grammar would be similar, you would
just make the empty string an invalid name and require the "=" sign,
and specify that failure to match means to ignore the whole thing.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 10:39:05 -0700

On Fri, Jul 16, 2010 at 6:42 AM, Julian Reschke <[email-masked]> wrote:
> occurs, that the first token and the remaining tokens have different roles,
> and how to parse the individual tokens.
>

What problem are we trying to solve by compressing this presentation?
The current presentation is only two pages of a 38 page document.
IMHO, parsing the set-cookie-string is the most important algorithm in
the document.  I think it's fine to dedicate 5% of the document to
getting it exactly right.

> - If part 2 / step 1 removes the leading semicolon, why include it in the
> first place?

Why not?  I doesn't matter from a conformance point of view.  It just
makes it easier for me to ensure that I've gotten everything 100%
correct.

> Speaking of which, is *anybody* confused about what these characters might
> be?

Sounds like an editorial issue.  You have your favorite pendantics, I have mine.

> - Instead of expressing a for-loop in prose, simply state that the string is
> to be split on semicolons, and a certain set of steps is to be applied to
> each fragment.

I don't see that as an improvement over the current text.

> I've heard that this part is exclusively for those who actually write the
> parsing code, and nobody else need to care. I disagree with that. If the
> spec makes normative requirements on handling non-conforming input, then it
> should be phrased in a way so that it's clear what gets processed how.

The current text is as clear as I can make it about how every sequence
of octets in a Set-Cookie header field is processed.

> Giving an example of a conforming algorithm is fine, but substituting the
> description with that algorithm IMHO is not.

IMHO, it is.  I guess we'll have to agree to disagree.

> For instance, when I debug an HTTP/cookie problem and look at an HTTP trace,
> I want to be able to understand how the recipient is going to parse the
> string. Reading the algorithm really isn't very helpful for that.

Actually, it should be very helpful.  Just mentally process the string
using the steps outlined in the document and you'll see exactly what
the UA is supposed to do.

> Also, if we need algorithms instead of format descriptions, why is it ok to
> define date parsing using an ABNF (see section 5.1.1)?

Would you prefer I switched the date parser to be more algorithmic?
In that case, I was able to find a precise presentation of the date
parsing algorithm that I thought would appeal more to IETF aesthetics.
 If you read that section carefully, you'll notice that the ABNF
doesn't tell the whole story about how to parse cookie-dates.  You
still need the algorithmic aspects below to get the right answer, but
I tried to make it as declarative as possible.

> and specify that failure to match means to ignore the whole thing.

I'm not familiar with EBNF (nor am I cheesed about introducing yet
another grammar type into this document).

I'm sure there are 1000 different presentations we could use for the
set-cookie-string parser.  The one we have seems fine to me.

Adam