max-age and httponly cookie attributes not appearing in cookies responseCookies

[yevon]

Hi! Just recently started using this amazing library, but I think I've found an issue with it. I realized that I'm not receiving the max-age attribute and http-only cookie attributes in the "responseCookies", but I can see them clearly when using my app through chrome dev mode:

Using latest version 1.20:

Response printed by karate:

Chrome dev:

[ptrthomas]

@yevon thanks, I think this is related to this comment: #1708 (comment)

so there's a bit of history - but I hope we can at least get some of these "missing" attributes working again.

it would be really great if you can find a public end-point that can simulate this. or any mock (ideally karate) server that helps you replicate this, perhaps you can hard code some header responses etc.

[yevon]

Yes, I think that it is the same. The responseCookies should be able to capture all cookie atrributes, even custom ones. I cannot provide a public IP but I think that this could be reproduced just making a GET request to google: https://www.google.es/. There are some cookies with those parameters set.

[yevon]

Find attached this example:

Feature: google cookies

  Background:
    * url 'https://www.google.com'

  Scenario: test google cookies

    Given path '/'
    When method get
    Then status 200

    * def first = response
    * print 'google cookies are: ', responseCookies

There are some parameters that doesn't match:

Karate:

Chrome:

[elafontaine]

Yes, that is linked to the cookie management as I identified in the other issue. This is a side effect of trying to manage the cookies and transferring between format (expiryDate vs max-age).

@ptrthomas I was doing some thinking on it, and I was wondering why we don't use the standard cookies system from the apache library (without trying to retain them ourselves in a separate cookieRegistry). If instead we exposed the cookies from the registry, then the management of them would be left to the librairies implementer while we took care of exposing the cookies in the registry. It would also simplify the logic I believe. Anyway, I'm unable to "work" on this at the moment... I would have to do it outside of work. I will look at it in my weekends.

I'm planning on looking if I could just remove the part below ( but keep the "headers = toHeaders..."). That way we don't clear the cookie store...

            // removing is probably not needed since apache cookie handling is enabled, but anyway
            httpResponse.removeHeaders(HttpConstants.HDR_SET_COOKIE);
            headers = toHeaders(httpResponse);
            headers.put(HttpConstants.HDR_SET_COOKIE, cookieValues);
            cookieStore.clear();

I'm still digging on the system and how this all interact everywhere.

[ptrthomas]

all: I think I managed a reasonable fix for this. so we use the proper "raw" headers as far as possible. in the edge case where we need to "fall back" to the apache cookie store, we merge them in and don't overwrite a fresh header. I think this solves all the reported issues and will last a while

[yevon]

Nice! Thanks all

[ptrthomas]

1.3.0 released

[yevon]

Thanks! Confirmed working nicely in 1.3.0.