Re: Éric Vyncke's Discuss on draft-ietf-httpbis-rfc6265bis-19: (with DISCUSS and COMMENT)

Hello Éric,

Thank you for your review and apologies for my late reply. I had to
take a hiatus.

> Trivial to fix: please use the actual BCP14 template include RFC 8174 reference.

Done

> Having some text about the difference with RFC 6265 would be helpful.

Appendix A. lists the major changes between this document and RFC 6265

> Unsure whether using "conformance" is the right word to be used in an IETF
> document. The BCP14 template has also little to do with conformance. Suggest
> using some wording related to "interoperation" rather than "conformance".
> Section 3.2 uses "compatible", which is more appropriate.

Conformance seems correct to me: "In order for an implementer to
conform to this specification, the following criteria must be met..."

> I am far from being an HTTP expert, but can CDN/proxies also set cookies ? It
> does not seem so when reading `a way for an origin server to send state`, if
> so, then suggest adding text clarifying whether CDN/proxies can also Set-Cookie

Anything with write access to the HTTP headers can, conceivably, set a
cookie including intermediaries such as proxies. I recall some load
balancers setting a cookie on the client in order to persist which
backend server the client is communicating with.

In these cases the intermediary is becoming the origin server for a
small aspect of the connection.

> As there are some text about deleting a cookie by sending a Expires date in the
> past, then the choice of `09 Jun 2021` for a valid cookie does not seem correct
> in 2025 ;-) Suggest adding some text in the 'valid' example stating that the
> request is sent in May 2021 or something similar.

Bumped the date to reduce confusion for the next several months
(hopefully after the document is published).

> To be honest and probably because I am not an HTTP expert, I was unable to
> understand the specification of SameSite...

How is it implemented or what's the point of it?

For the latter: One point is to prevent, for example, a malicious site
redirecting a user to a sensitive page which uses cookies for auth.

In a contrived example, let's say a user has important documents
stored on a cloud provider. If a site, https://evil.example, tries to
trick the user into clicking the confirm button on a hidden iframe for
https://cloudstorage.example/DeleteAllUserData

then SameSite={Lax,Strict} will prevent the auth cookies from being
sent which would cause the CSRF attack to fail. This is due to a
https://cloudstorage.example iframe on https://evil.example not being
the same site.

> Suggest adding "HTTP Header" to the section title, especially for section 4.2
> as I read it first about a section about cookies and not about the Cookie
> header.

Done.

> Who is the "We" in `We'll define this origin,`? The authors ? The HTTPBIS WG ?
> The IETF ? Please refrain from using the ambiguous "we", also applicable in
> other places

I rephrased the section to remove the "we"s.

> What are the consequences of bypassing the "SHOULD" in this section ? Also
> applicable to many SHOULD (e.g., section 6.1),

It's explained below "SHOULD be processed unless ignored according to
the user agent's cookie policy."

> recommended may be more
> appropriate.

Are SHOULD and RECOMMENDED not considered equivalents?

> Any justification for the 400 days ? Also, please explain the consequences of
> bypassing the "SHOULD".

It was chosen as a year + a bit more to allow for yearly events with
some wiggle room (along with 400 being a nice round number).

The consequences of ignoring the SHOULD are mild. Cookies can simply
exist in the cookie store for longer. One of the motivators for the
change was to reduce the number of stale cookies being stored, many
with expiries years in the future.

- Steven

Received on Monday, 17 November 2025 18:28:29 UTC