Use the HTTP cookie header when available, instead of the super global #240
Conversation
| * Parse a cookie header according to RFC 6265. | ||
| * | ||
| * PHP will replace special characters in cookie names, which results in other cookies not being available due to | ||
| * overwriting. Thus, the server request should take the cookies from the request header instead. |
There was a problem hiding this comment.
We ran into a problem with interacting with a Crowd SSO cookie which is named crowd.token_key but was getting set in $_COOKIE as crowd_token_key and requiring special handling to ensure that those two variants of the string match. This PR would solve that problem.
| for request parameters which were then registered as global variables. Due to this, cookies with a period | ||
| in the name were renamed with underlines. By getting the cookies directly from the cookie header, you have | ||
| access to the original cookies in the way you set them in your application and they are send by the user | ||
| agent. |
There was a problem hiding this comment.
Question: what happens if $_COOKIE is passed? fromGlobals() allows passing an array of cookies, and some of our documentation actually demonstrates passing in the superglobals explicitly. Should we discourage that behavior when it comes to cookies?
If so, we should likely add a note to that effect, and change some of the examples.
There was a problem hiding this comment.
If $_COOKIE is passed there, you get the old behaviour. Not sure if we need to discourage it though. This is a rare case which this PR fixes, and usually people will call fromGlobals() without arguments I suppose?
There was a problem hiding this comment.
Even if we don't actively discourage, it's probably worth adding a note stating what the expected result would be so that the mentioned examples are consistent with the new feature. @weierophinney is there a good search term or other way to locate the examples you are thinking of? I suppose fromGlobals and $_COOKIE would be a good place to start.
|
@sharifzadesina Putting a thumbs-down as a reaction without providing context as to why is not terribly useful. Next time, please provide a comment if you disagree. |
|
Marking as milestone 1.4.0, as it's a feature change/addition, and could impact users who are not passing |
Use the HTTP cookie header when available, instead of the super global Conflicts: CHANGELOG.md
|
Merged to develop for release with 1.4.0; thanks, @DASPRiD |
zend-diactoros 1.4.0 Added ----- - [zendframework#219](zendframework#219) adds two new classes, `Zend\Diactoros\Request\ArraySerializer` and `Zend\Diactoros\Response\ArraySerializer`. Each exposes the static methods `toArray()` and `fromArray()`, allowing de/serialization of messages from and to arrays. - [zendframework#236](zendframework#236) adds two new constants to the `Response` class: `MIN_STATUS_CODE_VALUE` and `MAX_STATUS_CODE_VALUE`. Changes ------- - [zendframework#240](zendframework#240) changes the behavior of `ServerRequestFactory::fromGlobals()` when no `$cookies` argument is present. Previously, it would use `$_COOKIES`; now, if a `Cookie` header is present, it will parse and use that to populate the instance instead. This change allows utilizing cookies that contain period characters (`.`) in their names (PHP's built-in cookie handling renames these to replace `.` with `_`, which can lead to synchronization issues with clients). - [zendframework#235](zendframework#235) changes the behavior of `Uri::__toString()` to better follow proscribed behavior in PSR-7. In particular, prior to this release, if a scheme was missing but an authority was present, the class was incorrectly returning a value that did not include a `//` prefix. As of this release, it now does this correctly. Deprecated ---------- - Nothing. Removed ------- - Nothing. Fixed ----- - Nothing.
PHP will replace special characters in cookie names, which results in other cookies not being available due to overwriting. Thus, the server request should take the cookies from the request header instead.