Closed
Bug 1217598
Opened 10 years ago
Closed 10 years ago
Cookie expiry doesn't accept floats
Categories
(Remote Protocol :: Marionette, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: titus.fortner, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: pi-marionette-server)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Steps to reproduce:
I sent this:
>>> http://localhost:4444/session/74c65937-ef83-5349-9bcc-f42c5c3993ad/cookie | {"name":"a","value":"b","secure":true,"path":"/set_cookie","domain":null,"expiry":1445559167.48654}
Actual results:
I received this: <- {"error":"invalid argument","message":"Failed to convert expiry to Date"}
Expected results:
When I send expiry as an integer, expected behavior occurs where it properly sets the cookie.
Comment 1•10 years ago
|
||
From the current WebDriver spec I would expect this to fail because expiry is supposed to be a date string, not a timestamp. So I guess marionette needs to change or the spec needs to change, or we need to accept this as an intentional protocol difference.
Also I don't see maxAge in the spec at all.
Comment 2•10 years ago
|
||
In my opinion WebDriver is too vague in this area about what input values it expects and which things it should error on. Precisely because there isn't a good specification we can rely on in this area, I feel WebDriver should call out the accepted input format and a suitable "invalid argument" error if it isn't met.
Add Cookie command: https://w3c.github.io/webdriver/webdriver-spec.html#add-cookie
Titus, can you provide me with some information on what Selenium sends?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(titus.fortner)
Updated•10 years ago
|
Blocks: webdriver
Keywords: ateam-marionette-server
| Reporter | ||
Comment 3•10 years ago
|
||
Weird, I would swear I used to get an expiry back when I sent an integer. Now I'm not getting nul returned. I'm using 44.0a1 (2015-10-19). Should I be using something else?
-> POST session/70bad149-9594-cf46-a338-68885928d8c9/cookie
>>> http://localhost:4446/session/70bad149-9594-cf46-a338-68885928d8c9/cookie | {"name":"foo","value":"bar","path":"/","secure":false,"expiry":2177452800}
> {"Accept"=>"application/json", "Content-Type"=>"application/json; charset=utf-8", "Content-Length"=>"74"}
1447268894803 Marionette DEBUG conn0 -> {"name":"addCookie","parameters":{"cookie":{"expiry":2177452800,"httpOnly":false,"name":"foo","path":"/","secure":false,"value":"bar"}},"sessionId":"70bad149-9594-cf46-a338-68885928d8c9"}
1447268894804 Marionette DEBUG conn0 client <- {}
<- {}
-> GET session/70bad149-9594-cf46-a338-68885928d8c9/cookie
Exception `RSpec::Expectations::ExpectationNotMetError' at /Users/tfortner/.rvm/gems/ruby-2.2.3/gems/rspec-expectations-2.99.2/lib/rspec/expectations/fail_with.rb:32 - expected nil to be a kind of DateTime
1447268894808 Marionette DEBUG conn0 -> {"name":"getCookies","parameters":{},"sessionId":"70bad149-9594-cf46-a338-68885928d8c9"}
1447268894809 Marionette DEBUG conn0 client <- [{"name":"foo","value":"bar","path":"/","domain":"localhost","httpOnly":false}]
<- {"value":[{"name":"foo","value":"bar","path":"/","domain":"localhost","expiry":null,"maxAge":null,"secure":false,"httpOnly":false}]}
Flags: needinfo?(titus.fortner)
Comment 4•10 years ago
|
||
The spec changed (I think) so that you need an object like {cookie: {name: foo, [...]}}
Possibly your client needs to be updated.
| Reporter | ||
Comment 5•10 years ago
|
||
Yes, I just filed that bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1223907. When I use cookie: {}, I get an exception. Passing in name & value works, just not when including an expiry.
Comment 6•10 years ago
|
||
In an attempt to tighten up the language around acceptable input types for adding cookies, I’ve submitted https://github.com/w3c/webdriver/pull/282 to the spec.
I don’t think it makes sense to accept cookies with an expiry time set as a decimal number since it’s supposed to be the number of seconds since Unix Epoch. The suggested patch to the spec mandates the value to be an integer.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Updated•3 years ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•