Re: [http-state] A question about the parser test data

[Adam Barth <[e-mail]>]

Thanks for these notes.  Comments below:

====
My model for the tests is as follows:

* "Set-Cookie:" headers are received in response from
  "http://home.example.org:8888/cookie-parser?TESTNAME".
  Consequently, default domain is "home.example.org" and default path
  is "/".

* "Cookie:" headers are those that would be sent back to the same URL,
  unless overridden by "Location:" header.  "Location:" header, if
  present, is relative to that URL.
====

[abarth] That's not quite right.  They're read from
"http://home.example.org:8888/cookie-parser-result?TESTNAME".  If you
run the Python script in test/run-test-server, that will actually spin
up an HTTP server you can use to test your implementation against.
You can look at run-test for examples of how to automate running all
the tests against your implementation.

====
The following all have issues with parsing of the "Set-Cookie:" header
that should give different behavior:

0021 don't expect "Cookie: x"; cookie-pair no good
NAME0017 expect no cookies; cookie-pair no good
====

[abarth] Fixed.

====
PATH0001 don't expect "Cookie: x=y"; path mismatch
PATH0002 don't expect "Cookie: a=b"; path mismatch
PATH0003 don't expect "Cookie: a=b"; path mismatch
PATH0004 don't expect "Cookie: x=y"; path mismatch
====

[abarth] These should work correctly once you interpret the final URL
as http://home.example.org:8888/cookie-parser-result?TESTNAME.

====
PATH0027 expect "Cookie: foo=bar"; explicit path should be ignored
====

[abarth] Fixed.

====
PATH0029 expect no cookies; path mismatch
====

[abarth] This should work correctly once you interpret the final URL
as http://home.example.org:8888/cookie-parser-result?TESTNAME.
Another possibility is that you're missing this step on page 22:

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

which is that this test intends to test.

====
These have issues with path matching the cookie path to the URL path:

ATTRIBUTE0023 expect no cookies; path mismatch
====

[abarth] This is likely the "cookie-parser-result" issue again.

====
ORDERING0001 expect "Cookie: key=val0"; path and domain should both match
====

val0 doesn't appear in the final cookie because

Set-Cookie: key=val2; path=/

overwrites it.  Notice that val0 gets the default path (which is / in
this case).  The check for removing old cookies with the same
name/domain/path occurs after the default path gets substituted for a
missing path attribute.

====
DISABLED_DOMAIN0032 and DOMAIN0014 are a bit of a puzzle.
Domain-parsing and host normalization rules don't say anything about
trailing dots.  So, strictly speaking, both tests should send no
cookies due to a domain mismatch.  However, one is expected to send a
cookie and the other not.  Given that a trailing dot is legitimate
syntax for DNS, I would think that ignoring trailing dots would result
in behavior that's different from today's implementations.
====

I've just deleted DISABLED_DOMAIN0032.  It's disabled because it's
actually testing something other than cookies (namely, URL
canonicalization).  DOMAIN0014, however, is a more reasonable test.
The point is that trailing dots in the Domain attribute aren't
canonicalized away (unlike leading dots).

Thanks for your detailed feedback.  I've pushed the fixes to github.

Adam


On Fri, Apr 8, 2011 at 3:02 PM, Chris Hanson <[e-mail]> wrote:
> I've attached my notes about the parser tests.  I tried to give enough
> detail so you can evaluate whether the data is wrong or my
> understanding is wrong; let me know if you need more.
>
> Chris
>
> On Fri, Apr 8, 2011 at 11:02 AM, Adam Barth <[e-mail]> wrote:
>> The test data isn't up to date with the final changes in the spec.  If
>> you'd be willing to send me the list of tests that don't match your
>> reading of the spec, I'll be happy to fix them.
>>
>> Thanks,
>> Adam
>>
>>
>> On Sun, Apr 3, 2011 at 10:08 PM, Chris Hanson <[e-mail]> wrote:
>>> I've recently built a cookie implementation that's intended to be
>>> (eventually) compliant with draft-23.  As part of my testing, I
>>> gobbled up the test data from https://github.com/abarth/http-state/
>>> and have been running my set-cookie parser on it.
>>>
>>> I've been seeing some anomalies between what it specifies and what I
>>> expect based on my reading of the spec.
>>>
>>> Are these tests intended to be true for compliant implementations?  Or
>>> are they just true for current browsers, and not necessarily for
>>> compliant implementations?  I suspect the latter but would like
>>> confirmation; otherwise I may need some help understanding why my
>>> reading of the spec is incorrect.
>>>
>>> Thanks in advance,
>>> Chris
>>> _______________________________________________
>>> http-state mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/http-state
>>>
>>
>