Personally, I no longer directly use these calls, preferring instead to use Symfony's HTTP foundation classes. Those in turn are, I understand, in the process of being converted to implement the common interface outlined here: http://www.php-fig.org/psr/psr-7/ I would be much more interested in seeing a bare bones implementation of that agreed on standard in the language core then seeing something entirely new, especially a band aid solution.
On Tue, Jul 18, 2017 at 1:49 PM, Andrey Andreev <n...@devilix.net> wrote: > Hi Andreas, > > On Tue, Jul 18, 2017 at 7:39 PM, Andreas Treichel <gmb...@gmail.com> > wrote: > > Hello Andrey, > > > >>> $options are equal to the optional parameters of setcookie and > >>> setrawcookie. > >>> $options may contain: > >>> > >>> expires: int > >>> path: string > >>> domain: string > >>> secure: bool > >>> httponly: bool > > > > > >> 1. The wording here implies that these are the *only* attributes > >> allowed. In the interest of forward-compatibility, I'd allow arbitrary > >> attributes as well. > > > > > > This are the only supported options in the current implementation. Future > > extension like samesite cookies can add more options. Unknown options are > > ignored and trigger a warning. > > > > That's what I was afraid of, and what I suggested be changed. > > If we had a similar, array-of-attributes API that did NOT ignore or > trigger warnings for unknown attributes, everybody using PHP would've > been able to use SameSite already. > > >>> encode is an additional option to remove the requirement of a raw and > non > >>> raw function. > >>> > >>> encode: int > >>> HTTP_COOKIE_ENCODE_NONE (same as setrawcookie) > >>> HTTP_COOKIE_ENCODE_RFC1738 (same as setcookie) > >>> HTTP_COOKIE_ENCODE_RFC3986 > > > > > >> 2. I don't think this is necessary, nor that it belongs in the $options > >> array. > > > > > > Most users dont know the correct encoding for cookies. This idea is from > the > > $enc_type parameter of http://php.net/http_build_query. The > documentation of > > http_cookie_set() should explain it the same way. > > > > Maybe i can move it out of the $options array and add an extra parameter > for > > the encoding, if the $options are the wrong location for this. > > > > On another note, I'd also move the 'expire' option to a separate > parameter and remove $options to $attributes. > > 'expire' is not a known cookie attribute; PHP uses it to calculate the > Expires and Max-Age attributes ... > > > > >> Anybody who'd use it, would have to read RFC1738 and/or RFC3986 to > >> know what they do. > > > > > > This is the same as setcookie(). No one has to read the rfc, which is not > > interested as it exactly works. HTTP_COOKIE_ENCODE_RFC1738 is the default > > for the encode option and encode the value the same ways as setcookie > encode > > it. > > > > the default values for the options are the same as thr parameters for the > > current setcookie(). The default values for the $options: > > > > expires: int, default: 0 > > path: string, default: "" > > domain: string, default: "" > > secure: bool, default: false > > httponly: bool, default: false > > encode: int, default: HTTP_COOKIE_ENCODE_RFC1738 > > > > > >> And as the constant names aren't particularly short either, it is > >> easier for me to just apply an encoding function directly to $value > >> before passing it. > > > > > > The current names of the constants are not short, but in most cases i > think > > you dont need it. > > > > > >> Also, RFC 6265 (section 4.1.1) only mentions Base64 as a suggestion > >> for encoding (and that's a SHOULD). > >> Link: https://tools.ietf.org/html/rfc6265#section-4.1.1 > > > > > > http_cookie_set() use the same encoding per default as setcookie(). > > > > Sorry, but this is kind of pointless then. I liked your proposal, > because it's a chance to have a shiny new API that doesn't come with > all the legacy stuff already built into setcookie(). > > But if we want an array-based setcookie() alternative without changing > anything else, we can just change setcookie() to accept arrays. In > hindsight, if this is really what you wanted, then I have to agree > with Dan - that is building on foundation of sand. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
