Subject: [http-state] draft-ietf-httpstate-cookie-09 questions

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Jul 2010 15:34:44 +0200

Section 3., paragraph 3:
OLD:

    Servers can send a Set-Cookie response header with any response.  An
    origin server can include multiple Set-Cookie header fields in a
    single response.  Note that folding multiple Set-Cookie header fields
    into a single header field might change the semantics of the header
    because the U+002C (",") character is used by the Set-Cookie header
    in a way that conflicts with such folding.

It's a bit confusing that the first sentence talks about servers and the
second about origin servers. Is this intentional?

Section 4.1.1., paragraph 9:
OLD:

    NOTE: Some user agents represent dates using 32-bit UNIX time_t
    values.  Some of these user agents might contain bugs that cause them
    process dates after the year 2038 incorrectly.  Servers wishing to
    interoperate with these user agents might wish to use dates before
    2038.

NEW:

    NOTE: Some user agents represent dates using 32-bit UNIX time_t
    values.  Some of these user agents might contain bugs that cause them
    to process dates after the year 2038 incorrectly.  Servers wishing to
    interoperate with these user agents might wish to use dates before
    2038.

s/cause them process/cause them to process/

Also: the whole advice doesn't sound very helpful. Maybe drop the whole
paragraph, or just the advice?

Section 12., paragraph 2:
OLD:

     The user agent MUST evict all expired cookies from the cookie store
     if, at any time, an expired cookie exists in the cookie store.

Hmmm?

That (a) reads strange, and (b) seems to be overspecification. I think 
it's totally ok for a UA not to evict cookies unless the cookie store is 
accessed.

Section 1., paragraph 8:
OLD:

         *  If the cookie's http-only-flag is true, then exclude the
            cookie unless the cookie-string is being generated for an
            "HTTP" API (as defined by the user agent).

This probably needs a reference to normative text that defines what an 
"HTTP" API is (maybe stuff for Section 2?).

(paragraph numbers generated by rfcdiff may be off. sorry)

---

From: Adam Barth <[email-masked]>
Date: Tue, 13 Jul 2010 08:48:36 -0700

> second about origin servers. Is this intentional?

Nope.  Presumably "origin server" is more accurate?

> paragraph, or just the advice?

I've removed the advice, but left the statement of fact (and fixed the typo).

> That (a) reads strange, and (b) seems to be overspecification. I think it's
> totally ok for a UA not to evict cookies unless the cookie store is
> accessed.

It's a model.  User agents can do anything that's observationally
equivalent.  From a specification point of view, it's easier to write
this sentence and then ignore expired cookies throughout the reset of
the model.  I expect most user agents will meet this requirement
lazily.

> "HTTP" API is (maybe stuff for Section 2?).

The notion of a non-HTTP API is not defined by this specification.
It's an opaque term that higher level specifications can use when
defining their APIs.  (See the recent discussion on this list about
HTML5 defining document.cookie to be a non-HTTP API.)

> (paragraph numbers generated by rfcdiff may be off. sorry)

No problem.  It's easy to find the text you mean.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jul 2010 09:19:36 +0200

On 13.07.2010 17:48, Adam Barth wrote:
> On Tue, Jul 13, 2010 at 6:34 AM, Julian Reschke<[email-masked]>  wrote:
>> Section 3., paragraph 3:
>> OLD:
>>

See terminology in 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.1.3>... In 
this case, origin server seems to be right. (I'd also make these two 
paragraphs; the second being about the multiple header topic exclusively).

> equivalent.  From a specification point of view, it's easier to write

I don't think this is clear from the spec.

> the model.  I expect most user agents will meet this requirement

Indeed, so maybe we should phrase it this way.

> HTML5 defining document.cookie to be a non-HTTP API.)

I don't think we can make normative requirements that depend on an 
undefined term.

> ...

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Wed, 14 Jul 2010 09:03:04 -0700

> I don't think this is clear from the spec.

Sayeth the draft:

[[
   Conformance requirements phrased as algorithms or specific steps can
   be implemented in any manner, so long as the end result is
   equivalent.  In particular, the algorithms defined in this
   specification are intended to be easy to understand and are not
   intended to be performant.
]]

> Indeed, so maybe we should phrase it this way.

The lazy implementation is more complex to explain and less clear.  I
don't think adding the phrase "check for expired cookies" everywhere
needed would be an improvement.

> I don't think we can make normative requirements that depend on an undefined
> term.

Well, there's no way for this spec to know what kind of API is calling
it.  That's up to the folks who define the APIs.  Think of it as an
input parameter to the model.

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 14 Jul 2010 18:12:53 +0200

On Wed, 14 Jul 2010 18:03:04 +0200, Adam Barth <[email-masked]> wrote:
>> undefined

I think what Julian is asking for is documentation on the parameter (maybe  
this already exists, I have not checked). E.g. "The non-HTTP API flag is  
defined by this specification so that other specification can reuse the  
algorithms outside an HTTP context." or some such.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jul 2010 18:16:59 +0200

On 14.07.2010 18:12, Anne van Kesteren wrote:
> I think what Julian is asking for is documentation on the parameter
> (maybe this already exists, I have not checked). E.g. "The non-HTTP API
> flag is defined by this specification so that other specification can
> reuse the algorithms outside an HTTP context." or some such.

Something like that; it should make clear what part of the requirements 
are specific to higher layers in the stack...

BR, Julian

---

From: Adam Barth <[email-masked]>
Date: Wed, 14 Jul 2010 10:15:44 -0700

> algorithms outside an HTTP context." or some such.

Here's what we say in that regard:

[[
            <t>The HttpOnly attribute limits the scope of the cookie to HTTP
            requests. In particular, the attribute instructs the user agent to
            omit the cookie when providing access to cookies via "non-HTTP"
            APIs (such as a web browser API that exposes cookies to
            scripts).</t>
]]

Adam

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2010 14:11:23 +0200

On 14.07.2010 18:03, Adam Barth wrote:
> On Wed, Jul 14, 2010 at 12:19 AM, Julian Reschke<[email-masked]>  wrote:

Yes.

> needed would be an improvement.

I disagree. Stating X when we mean Y is confusing; even if we earlier on 
said that both are equivalent.

> input parameter to the model.

Well.

1) If we put these kind of hooks into the spec, then we should at least 
present them in a way that makes clear what they are.

2) That being said, I was asking for a definition of "HTTP API", not 
"non-HTTP API".

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jul 2010 14:25:48 +0200

On 14.07.2010 19:15, Adam Barth wrote:
> On Wed, Jul 14, 2010 at 9:12 AM, Anne van Kesteren<[email-masked]>  wrote:
>> On Wed, 14 Jul 2010 18:03:04 +0200, Adam Barth<[email-masked]>  wrote:

Maybe some of the confusion is based on the terminology...? Why are we 
talking of an API when describing the role of this header in HTTP?

Best regards, Julian