Hello,

1. According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date the date format whould be 'D, d M Y H:i:s T' instead of 'D, d-M-Y H:i:s T' I have seen (and used) both the formats, but I tend to follow MDN specs.

2. Should we also be able to set the expiration dat using a cookie ttl/lifetime value instead of the actual expiry date/timestamp, so that both Expires and Max-Age can be added to the header? (btw, calculating Max-Age from timestamp would not be good as we would have to subtract current time() that in the (toHeaderValue)-call could accidentally yield an extra second since it was set) . Maybe a simple thatExpiresIn() method.

kind regards, maks

Hey! Thank you for the awesome package. Some questions;

• Is there any way I could remove a cookie with this package?
• (If not) Would you implement a method to remove a cookie?

Hi! I've been using this library for a while now. I'm curious - why remove the cookie signing and RequestCookies classes? That functionality is far from useless. We use RequestCookies to unpack cookies from a PSR-7 request ...

Hello!

First of all, I want to say thank you for your library! I'm using it on top of zend-expressive and someone is trying to hack the website by sending wrong request data (integer cookie name). So I see this error in logs:

[0] TypeError: Argument 1 passed to HansOtt\PSR7Cookies\Cookie::__construct() must be of the type string, integer given, called in vendor/hansott/psr7-cookies/src/RequestCookies.php

Is it possible to cast cookie name to string before creating Cookie instance?

Samesite=none is a valid value, however the validation does not currently allow this.

This blog post highlights when you'd want to use this value: https://web.dev/samesite-cookie-recipes/ Cookies for cross-site usage must specify SameSite=None; Secure to enable inclusion in third party context.

The Cookie class constructor accepts only strings as cookie $value, but there are cases where it could get an array. For example, if a cookie is sent like this:

curl -v -k --cookie "array_name[0]=someValue" http://127.0.0.1:5000

In this case, PHP is converting the cookie header value into an array; so, the ServerRequestInterface::getCookieParams() method returns this:

Array
(
    [array_name] => Array
        (
            [0] => someValue
        )

)

This causes RequestCookies::createFromRequest() to fail when creating a new Cookie() object for each cookie header set into the ServerRequestInterface object; that's because an array it's passed instead of a string, for argument 2. I would recommend to keep an eye on data sanitisation when fixing it, as this could possibly lead to code injection from malicious requests.

Currently it's kind of a PITA to set custom properties for cookies...

e.g. you want to set a normal cookie with SameSite specified (or maybe combined with a expires in)

Goals:

• You can set individual parameters (with immutable API)
• There are multiple ways to define time component: expires at, expires in, seconds valid, ... (This also needs to be testable, so a clock as dependency would be nice)
• You cannot create an invalid cookie
• It just works!
• The current methods are preserved for backwards compat