- From: Daniel Stenberg <daniel@haxx.se>
- Date: Mon, 2 Dec 2024 20:35:06 +0100 (CET)
- To: Rory Hewitt <rory.hewitt@gmail.com>
- cc: David Benjamin <davidben@chromium.org>, Watson Ladd <watsonbladd@gmail.com>, Stefan Eissing <stefan@eissing.org>, Yoav Weiss <yoav.weiss@shopify.com>, David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, 2 Dec 2024, Rory Hewitt wrote: > Short of creating a new 'Set-Cookie2' and 'Cookie2' response/request header > pair that only allow a very well-documented set of characters, there is no > obvious solution. I think the solution is to A) keep improving the spec and perhaps more importantly B) keep reporting bugs on implementations that fail to follow it and C) actually fix the flawed implementations. RFC 6265 apparently was possible to create, and it added lots of restrictions that previously did not exit (in spec) because we agreed that is what cookie implementations need. RFC 6265bis is coming with cleanups and clarifications which ideally should help us interop even more. Several of the issues mentioned in the article by April that started this thread can in fact be worked on already now as they identify spec violations. A challenge with cookies in general is that there are so many different and separate implementations to check and fix, rather than just a few major libraries. > Frankly, I'd be happy to see the creation of a 'Set-Cookie-Ascii' and > 'Cookie-Ascii' header pair... Set-Cookie2 was attempted (and failed) in RFC 2965 (published in 2000). I don't think would be any easier to introduce a new header for this now. -- / daniel.haxx.se
Received on Monday, 2 December 2024 19:35:11 UTC