[wp-trac] [WordPress Trac] #43231: Wp_Http_Cookie host-only flag

[WordPress Trac]

#43231: Wp_Http_Cookie host-only flag
--------------------------+-----------------------------
 Reporter:  soulseekah    |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  HTTP API      |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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".

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43231>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform