ResponseCookie to allow leading dot in domain name again

[rubasace]

ResponseCookie was changed and now applies Rfc6265Utils to validate attributes. As stated on issue #23776, we should be strict with output and lenient with input. Reality is that ReactorClientHttpResponse and JettyClientHttpResponse are using ResponseCookie to propagate cookies received. This scenario is cleary input and yet it's still failing when hitting endpoints behind Cloudflare, as they add the HttpOnly cookie with domain=.domain.com as stated here.

Regarding possible solutions, I think the builder itself could have some kind of flag to disable validation, allowing both ReactorClientHttpResponse and JettyClientHttpResponse use it when just propagating cookies from the cookie header.

[rstoyanchev]

Fair point that for a ClientHttpResponse this represents input.

It makes sense to separate validation from the building of a cookie, so that a client response. Perhaps we can add a validate() method on ResponseCookie that can be invoked by server responses and could also be called by any code that's consuming response cookies from the client side.

[rubasace]

I think both make sense, depending on where it's more used, if client or server. What are your thoughts regarding an alternative skipValidation() on the builder so all existing behaviour needs no change apart from the failing clients?

[JorritSalverda]

After opening a support ticket with our CDN provider we received the following response:

I've reviewed the RFC and there may be some misinterpretation here:

If the first character of the attribute-value string is %x2E ("."):

  Let cookie-domain be the attribute-value without the leading %x2E
  (".") character.

Otherwise:

  Let cookie-domain be the entire attribute-value.

This is saying that if the value of the domain ( domain=) starts with a . then ignore it otherwise if it doesn't begin with a . use the entire value.

This indeed seems to point at your implementation being a bit too strict for pretty common input. Hope this can be made more liberal soon :)

[rstoyanchev]

@JorritSalverda that quote is from section 5.2.3 which is for "User Agent Requirements". The server requirements in 4.1 however point to https://tools.ietf.org/html/rfc1034#section-3.5.

As far as "soon" is concerned, the ticket has a target milestone and a backport scheduled.

[rstoyanchev]

@rubasace regarding skipValidation I think it is preferable to have an affirmative API when possible, but another in between alternative might be to add domain(String domain, boolean validate).

That said I am also considering just dropping the rejection of a leading ".". It seems to have caused quite a bit of disruption and clients are instructed to ignore it by the RFC.

[rubasace]

@rstoyanchev definitely agree on the affirmative API.

Regarding the domain(String domain, boolean validate) vs dropping the rejection I'm more inclined on dropping the validation too, as it seems to be different interpretations of the RFC.