[http-state] Question regarding RFC 6265 and ietf process
0 views
Skip to first unread message
Fagner Martins
Sep 5, 2015, 7:06:46 PM9/5/15
to http-...@ietf.org
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!
Daniel Stenberg
Sep 6, 2015, 2:07:31 PM9/6/15
to Fagner Martins, HTTP-state mailing list
On Tue, 1 Sep 2015, Fagner Martins wrote:
> 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
> 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
> it actually work instead of restricting only to how browsers work in the
> wild.
The work on RFC 6265 was certainly not just to document how browsers work. We
> wild.
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
_______________________________________________
http-state mailing list
http-...@ietf.org
https://www.ietf.org/mailman/listinfo/http-state
Fagner Martins
Sep 7, 2015, 9:03:25 AM9/7/15
to Daniel Stenberg, HTTP-state mailing list
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.
Reply all
Reply to author
Forward
0 new messages