sashahart/cookies — pull request #5 by sashahart (2014-03-27 04:32:32+00:00)
Title: stop parse_domain from stripping initial dot?

Hmm. What do others think about this?

parse liberally, render conservatively - of course I'm keeping that. But as currently written, there are strings which are neither 'reject this cookie/attribute' nor 'pass it on downstream' - like the initial dot on domain attributes found in set-response strings, which I am silently allowing but stripping *during parse*.

Is it the parser's responsibility to preserve original information where there's a strong case that it's useful? But if so, doesn't that make it the caller's responsibility to strip that information to ensure sanity/compliance? And if that would have to be done routinely as part of basic good practice, is it really "friendly" for cookies to pass the buck to every single user there (e.g. to write some awful wrapper, like sane_cookies)?

---

Unlike spaces and quotes, this initial dot character could carry information
that might be of interest to the caller who is parsing a Set-Response line.

Arguably it should be up to the user-agent itself, not the parsing library
called by the user-agent, to ignore the initial dot.

After all, I went far enough to leave the initial dot in DOMAIN_AV regexp specifically to
let this initial period through... and also wrote in a comment:

# Domains starting with periods are not RFC-valid, but this is very common
# in existing cookies, so they should still parse with DOMAIN_AV.

Then I wrote DOMAIN_AV so that the attribute would parse without vomiting.

Perhaps, as a separate change, generated renders should strip the dot.
At least via the default renderer.