Subject: [http-state] Question regarding RFC 6265 and ietf process

From: Fagner Martins <[email-masked]>
Date: Tue, 1 Sep 2015 12:16:54 -0300

Hi.

Sorry to bother but I really have no idea who to ask about this and I hope
I came to the correct mailing list.

A few weeks ago I did implemented a JavaScript library to handle
client-side cookies using the RFC 6265 as a baseline to percent-encode only
the cookie characters that are not allowed in the RFC, see
https://github.com/js-cookie/js-cookie/tree/f28a0fdfc0f780406a4f083c1ec410c77acf55ec#encoding
.

The thing is that recently we found out that some frameworks and
server-side programming languages, for historical reasons, do not accept a
character that the RFC allows. Here an example of the "+" octet:
https://github.com/js-cookie/js-cookie/issues/70#issuecomment-126965203

Unfortunately those languages and frameworks cannot change the way they
handle cookies because in most of them the default cookie mechanism is
built-in very hard into the internals of the language/framework, and even
if they could, it would take time for the implementation reach to the
developers hand.

I am not a veteran on the internet, so I am not aware of how the process
works. But would it make sense to amend the RFC to account for characters
allowed in the browsers but realistically disallowed by most frameworks due
to historical reasons?

It would be very useful to make the RFC a documentation to serve as a
baseline for how the web *and the server-side languages *that are built on
it actually work instead of restricting only to how browsers work in the
wild.

Does it makes sense?

Thanks!
----------------------------------------------------
Fagner Martins Brack
http://www.fagnerbrack.com/
https://github.com/FagnerMartinsBrack?tab=activity
http://stackoverflow.com/users/1400037/fagner-brack
http://br.linkedin.com/pub/fagner-martins-brack/69/48/719

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 6 Sep 2015 20:07:17 +0200 (CEST)

> it actually work instead of restricting only to how browsers work in the 

The work on RFC 6265 was certainly not just to document how browsers work. We 
worked on documenting how cookies are used in general everywhere on the web 
and I can't recall anyone mentioning this restriction during that process.

But also, this restriction seems very arbitrary and random and I don't see how 
any spec in the cookie history has made these frameworks make this decision. 
My personal opinion is that this is an implementation bug, not a problem with 
the spec.

-- 

  / daniel.haxx.se

---

From: Fagner Martins <[email-masked]>
Date: Mon, 7 Sep 2015 10:00:17 -0300

It seems that the plus decode handling for php and rack are happening way
before the spec was released in 2011. See
https://github.com/js-cookie/js-cookie/issues/70#issuecomment-138290406

AFAIK, before RFC 6265 there was no consensus regarding how to handle
cookies, I could rise some bug report in each specific language, but since
php is so widely used in the web I am pretty sure they are not going to
change it.
----------------------------------------------------
Fagner Martins Brack
http://www.fagnerbrack.com/
https://github.com/FagnerMartinsBrack?tab=activity
http://stackoverflow.com/users/1400037/fagner-brack
http://br.linkedin.com/pub/fagner-martins-brack/69/48/719

2015-09-06 15:07 GMT-03:00 Daniel Stenberg <[email-masked]>:

> The work on RFC 6265 was certainly not just to document how browsers work.
> We worked on documenting how cookies are used in general everywhere on the
> web and I can't recall anyone mentioning this restriction during that
> process.
>
> But also, this restriction seems very arbitrary and random and I don't see
> how any spec in the cookie history has made these frameworks make this
> decision. My personal opinion is that this is an implementation bug, not a
> problem with the spec.
>
> --
>
>  / daniel.haxx.se
>