webdriver
webdriver copied to clipboard
Clarification for "Add Cookie" behavior when trying too set a secure cookie for a non-secure connection
In chapter 14. Cookies, section 14.3 Add Cookie:
Create a cookie in the cookie store associated with the active document’s address using cookie name name, cookie value value, and an attribute-value list of the following cookie concepts listed in the table for cookie conversion from data: .. If there is an error during this step, return error with error code unable to set cookie.
It's not that clear by the spec if the cookie should not be set and success
returned (as currently done by chromedriver), or similar to other commands a proper error (unable to set cookie
) being returned.
If we wont return an error, and the cookie isn't set the webpage/app under test might misbehave at some point. It would not be clear why, and investigation isn't that trivial.
@JohnChen0, @burg, @shs96c what is your take here?
This strikes me that the cookie jar should be erroring here and then webdriver should just pass on that it couldn't set the cookie which is already in the spec
Our take is that it should return an error because of the mismatch between http url and secure flag. I filed a bug against DevTools for Network.setCookie that it should not succeed in this case.
Great to hear that. Thanks Shengfa!
@AutomatedTester is there anything we should update in the WebDriver spec, or is that change of behavior someone implicit?
So, now I'm confused, because @JohnChen0 said the previous Chrome behavior was correct:
- Adds secure cookie regardless of protocol
- Does not retrieve secure cookie when non-secure protocol
- Does retrieve secure cookie when secure protocol
This behavior matches my reading of the spec:
driver.get 'http://example.com/'
driver.manage.all_cookies.size # ==> 0
driver.manage.add_cookie name: 'foo', value: 'bar', secure: true
driver.manage.all_cookies.size # ==> 0
driver.get 'https://example.com/'
driver.manage.all_cookies.size # ==> 1
Alex noted here that Chrome 89 changed behavior where it does retrieve the cookie from a non-secure protocol, but as far as I can tell, it only changed on localhost, and it still does not work on http://example.com
, and either way this change is a new bug.
fwiw, the behavior described in my example above is what Safari & IE are doing right now as well.