edgedb icon indicating copy to clipboard operation
edgedb copied to clipboard

Send `clear-site-data` header for invalid cookies

Open scotttrinh opened this issue 1 month ago • 4 comments

Instead of silently swallowing invalid cookie headers, we return an error and send clear-site-data: "cookies" in the response header. This reverts the custom, tolerant cookie parser we added in the base branch back to the built-in one.

Some additional notes:

  • Errors that cause the httptools.parser itself to fail (like including non-ASCII characters) do not get caught here.
  • Maybe we want to just continue with an empty cookie jar while ensuring that the response has the clear-site-data header set instead of erroring?

scotttrinh avatar Oct 31 '25 13:10 scotttrinh

On localhost I think everything (like the gel server, the user's app, etc.) all share the same cookies, so this would also wipe any cookies the user app has set as well right? Is that the intention?

jaclarke avatar Oct 31 '25 14:10 jaclarke

On localhost I think everything (like the gel server, the user's app, etc.) all share the same cookies, so this would also wipe any cookies the user app has set as well right? Is that the intention?

I think cookies are bound to the host + post, right?

scotttrinh avatar Oct 31 '25 19:10 scotttrinh

On localhost I think everything (like the gel server, the user's app, etc.) all share the same cookies, so this would also wipe any cookies the user app has set as well right? Is that the intention?

I think cookies are bound to the host + post, right?

No, just the host: https://datatracker.ietf.org/doc/html/rfc6265#section-8.5

jaclarke avatar Oct 31 '25 19:10 jaclarke

On localhost I think everything (like the gel server, the user's app, etc.) all share the same cookies, so this would also wipe any cookies the user app has set as well right? Is that the intention?

[...]

No, just the host: https://datatracker.ietf.org/doc/html/rfc6265#section-8.5

Ahh, thanks for the chapter and verse on that! 🙏

Given that, I'm fine with not doing this. I guess an alternative to this would be to detect which cookie failed to parse and send a new cookie header to "delete" that cookie, but I think now we're getting far afield from the original intention here. Should I just close this and maybe we stick with the behavior in the base branch? @mmastrac since you made this suggestion, wdyt about the possibility of accidentally having a larger blast radius than intended?

scotttrinh avatar Nov 03 '25 14:11 scotttrinh