Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1266

Fix cookie processing

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 3.1.0.CR1, 3.0.20.Final
    • 3.0.6.Final, 3.0.13.Final
    • jaxrs
    • None
    • Hide
      1. Create a @PreMatching ContainerRequestFilter with the above code in it.
      2. Create a resource that looks for a cookie with the NEW_COOKIE_NAME name
      3. Make a request with a cookie with the OLD_COOKIE_NAME name

      Expected behavior: the filter sees the "old cookie" and "creates" a "new cookie" for resources and downstream filters, and the resource can thus see the "new cookie".

      Actual behavior: the resource does not see such a cookie.

      Workaround: the resource has to explicitly check for both cookies.

      Show
      Create a @PreMatching ContainerRequestFilter with the above code in it. Create a resource that looks for a cookie with the NEW_COOKIE_NAME name Make a request with a cookie with the OLD_COOKIE_NAME name Expected behavior: the filter sees the "old cookie" and "creates" a "new cookie" for resources and downstream filters, and the resource can thus see the "new cookie". Actual behavior: the resource does not see such a cookie. Workaround: the resource has to explicitly check for both cookies.

    Description

      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:

      Attachments

        Issue Links

          incorporates

          Bug - A problem that impairs or prevents the functions of the product. RESTEASY-1516 Cookies sent by resteasy-client are not spec compliant

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Open

          Activity

            People

              rsigal@redhat.com Ronald Sigal
              t.broyer Thomas Broyer (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: