Re: Delete-Cookie header??

On Sat, Mar 01, 2025 at 06:02:43PM +0100, Daniel Stenberg wrote:
> On Fri, 28 Feb 2025, Daniel Veditz wrote:
> 
> > But what were the rfc6265 authors supposed to do? Define only the
> > "strict" rules consistent with the two previous cookie RFCs
> 
> IMHO the spec should document the *single* Set-Cookie syntax in one place.
> 
> Here's a longer description on my blog for those who care:
> 
>   https://daniel.haxx.se/blog/2025/03/01/my-cookie-spec-problem/

I must admit I never liked at all the approach consisting in explaining
how to parse algorithmically. This doesn't even fit well into existing
models which have to care about various error processing, captures for
reporting etc. For me this has always been extremely confusing since
6265. Worse, algorithmic bugs in such a spec are not 100% avoidable and
can result in all implementations failing on specific patterns and
suddenly diverging when trying to fix the problem.

I admit that we need to be conservative in what we send and liberal in
what we accept but I'd prefer to see the whole (complex) syntax, then
a sender part saying "you should not do this and that", and a consumer
part saying "you may reject this and that".

Normally when you're a sender and the spec says that your peer MAY reject
what you're going to send, you're more careful about avoiding it, and I
think it's how we got rid of a number of issues in various protocol
extensions over the years. At least it's how I'm seeing it.

I've long considered this particularity of 6265 is in part responsible
for servers not trying to refine what they send, since they're offered
the super-lax algorithm recommended to clients as an example of how to
abuse them in the widest possible form.

Regards,
Willy

Received on Saturday, 1 March 2025 18:25:34 UTC