Re: I-D Action: draft-ietf-httpbis-cookie-prefixes-00.txt

I would like to submit an objection to 
"draft-ietf-httpbis-cookie-prefixes-00.txt".


http://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00

>    3.  Prefixes  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
>      3.1.  The "__Secure-" prefix  . . . . . . . . . . . . . . . . .   3
>      3.2.  The "__Host-" prefix  . . . . . . . . . . . . . . . . . .   3


The `-` U+002D "HYPHEN-MINUS" character, commonly referred to as "dash", 
is not a valid identifier in most languages, whereas an underscore is.


See "word", [[:<:]] and [[:>:]] in re_format(7):

   http://mdoc.su/n/re_format.7

>      characters which is neither preceded nor followed by word characters.  A
>      word character is an alnum character (as defined by ctype(3)) or an
>      underscore.  This is an extension, compatible with but not specified by


See "word", \w, \W, \b, \B etc in pcrepattern(3):

   http://mdoc.su/n/pcrepattern.3

>        A "word" character is an underscore or any character that is  a  letter
>        or  digit.   By  default,  the definition of letters and digits is con-


I did see your arguments that Cookie names are allowed to have even more 
"exotic" characters than a mere dash, however, what I haven't seen is 
any good argument of why going against the flow in this very instance is 
of any benefit to anyone.

There are already people trying to figure out how to use this spec with, 
for example, nginx, and they're falling short, because current versions 
of nginx do not appear to support such syntax for cookies (unless you go 
looking into `$http_cookie` directly with `map` and regex, which is 
entirely doable, but will definitely slow you down).  I'm pretty sure 
nginx.conf is not the only language where this decision will cause these 
little issues and slowdowns for absolutely no good reason nor benefit.

I opened up Cookie Manager of my favourite browser.  I briefly looked at 
some of the Cookie Names used.  I found that, subjectively, underscores 
are used by about 90% of users, whereas dashes appear in at most 5%, if 
not much less.

There appears to be little reason to not name `__Secure-` and `__Host-` 
as `__Secure_` and `__Host_`, respectively, which would avoid this issue 
entirely.

Who else is likely to use the names starting with double underscores? 
Users that are trying to define their own unique namespace to not clash 
with the namespace of the rest of the site.

Then, what we have to ask ourselves is this -- should 99,9999% of people 
be inconvenienced with non-identifier characters because some people may 
have though that "__Host_" or "__Secure_" was a good non-RFC namespace 
for their non-RFC use, or should they be the ones that face breakage for 
the benefit of 99,9999% of the internet not having to figure out how to 
access these cookies with non-identifier characters through their 
language of choice?

Cheers,
Constantine.

http://Constantine.SU/
http://www.netbsd.org/people/developers.html#cnst

Received on Thursday, 7 July 2016 04:11:59 UTC