Re: Delete-Cookie header??

On Tue, Feb 25, 2025 at 2:41 PM Daniel Stenberg <daniel@haxx.se> wrote:
> > RFC 6265 did not create that problem, it tried to make sense of how the web
> > was already working.
>
> I disagree quite strongly. It is not about who "created that problem". I don't
> even quite understand which problem that is.
>
> Basically all client-server protocols have this nature of two sides of the
> story.

It wasn't client vs server, it was implementations that followed the
previous specs, more or less, vs servers and browsers that had been
"innovating at Internet Speed" during the dot-com bubble. It looks to
me like an attempt to encapsulate Postel's Law into the spec. Servers
SHOULD follow the conservative syntax in section 4 (but not all did),
and section 5 describes how users agents implement "liberal in what
they accept" in a compatible way.

It would have worked fine if cookies were only ever echoed back to the
server that created them; the UA would accommodate however
conservative or liberal the server and web application happened to be.
Sibling domains that share cookies raise the risk since they might be
running server software with different rules, but the big wrench in
the works is "document.cookie". That lets cookies be created under the
user agent's "liberal" rules that might not align with what the server
software can handle. Problems could come from bugs in the website code
or from XSS. Or bugs/XSS in a sibling domain the application dev has
no control over in a big organization.

But what were the rfc6265 authors supposed to do? Define only the
"strict" rules consistent with the two previous cookie RFCs, and then
be ignored like the two previous cookie RFCs? User agents couldn't
afford to break all the sites from the dot-com bubble and after that
took advantage of the "innovations".

> I claim it confuses readers and makes the spec hard to read and
> repeatedly misunderstood.

I agree.

> The question is *how* to document.

Indeed, how? It would be much easier to document if reality weren't so messy.

-Dan Veditz

Received on Friday, 28 February 2025 23:55:55 UTC