Hi Andreas, 2017-07-18 18:39 GMT+02:00 Andreas Treichel <gmb...@gmail.com>:
> 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. > > > 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. > > > 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(). > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > As an average developer, I see providing new functions with http_ prefix more meaningful and their API more simple because of fewer parameters I need to pass. Although however, I see the naming convention you've used is rarely used. Looking in the docs, there are few other HTTP sapi related functions which don't follow that convention, like: header() - Send a raw HTTP header header_remove() - Remove previously set headers header_register_callback() - Call a header function headers_sent() - Checks if or where headers have been sent - this function uses referencing for retrieving the file name and line number :/ ughhhh... headers_list() - Returns a list of response headers sent (or ready to send) http_response_code() - Get or Set the HTTP response code - which is THE ONLY ONE function prefixed this way I just wanted to pay attention to a different naming convention which actually exists in language, which may need to be taken as a pursuit for all HTTP related functions. I like http_ prefixed functions because they point HTTP related nature and I think it may clear a little bit language API. P.S. headers_list() may be used to retrieve all headers which are sent (or ready to send) so you might consider introducing http_cookies_list() to retrieve all set (and not removed) cookies in current request lifecycle. Cheers, -- regards / pozdrawiam, -- Michał Brzuchalski about.me/brzuchal brzuchalski.com
