Opened 7 years ago
Closed 6 years ago
#43231 closed defect (bug) (fixed)
Wp_Http_Cookie host-only flag
Reported by: | soulseekah | Owned by: | pento |
---|---|---|---|
Milestone: | 5.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | HTTP API | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
The Wp_Http_Cookie
as parsed from the Requests_Cookie
does away with some very important information - the host-only flag.
Consider the following example header that a remote server sends:
Set-Cookie: test=12345; domain=".example.org"
This is transformed into a Requests_Cookie
with the domain attribute set as "example.org" (as per RFC 6265 https://tools.ietf.org/html/rfc6265#section-5.3 point 6 (domain-attribute storage model)) and a "host-only" flag is set to false, which means that the cookie can be sent to any subdomains within the domain.
Then the Request_Cookie
is transformed into a Wp_Http_Cookie
, which doesn't store any of the flags at all. This results in a cookie that is only valid for the main domain, since "host-only" is a true-by-default flag.
It is now impossible to send the same Wp_Http_Cookie
instance to the next request as it gets filtered out by Request_Cookie
domain-matching https://github.com/rmccue/Requests/blob/master/library/Requests/Cookie.php#L131) and never gets sent.
The only workaround is to null the domain
property of the Wp_Http_Cookie
to allow it to be sent to a subdomain.
So in short, Wp_Http_Cookie
is losing very important information, i.e. the difference between ".example.org" and "example.org".
Initial tests