-
Bug
-
Resolution: Done
-
Major
-
3.0.6.Final, 3.0.13.Final
-
None
I'm trying to write a @PreMatching ContainerRequestFilter to seamlessly migrate cookies from one name to another.
For that, the code looks more-or-less like:
public void filter(ContainerRequestContext requestContext) throws IOException { final Cookie cookie = requestContext.getCookies().get(OLD_COOKIE_NAME); if (cookie != null && requestContext.getCookies().containsKey(NEW_COOKIE_NAME)) { requestContext.getHeaders().add(HttpHeaders.COOKIE, new Cookie(NEW_COOKIE_NAME, sidCookie.getValue()).toString()); } }
Resources and downstream filters however don't see the new cookie in getCookies(). This is because cookies are computed when the ResteasyHttpHeaders instance is created (e.g. ServletUtil#extractHttpHeaders or NettyUtil#extractHttpHeaders) and then live their life independent of the headers.
Looking at the JAX-RS reference implementation, getCookies() seems to be computed on-the-fly, extracted from headers:
- https://github.com/jersey/jersey/blob/b7907e279010e7035a7a3e529993d22f77a21e08/core-server/src/main/java/org/glassfish/jersey/server/ContainerRequest.java#L550-L553
- https://github.com/jersey/jersey/blob/b7907e279010e7035a7a3e529993d22f77a21e08/core-common/src/main/java/org/glassfish/jersey/message/internal/InboundMessageContext.java#L534-L552
- incorporates
-
RESTEASY-1516 Cookies sent by resteasy-client are not spec compliant
- Open