Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99908
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <86.8B.02884.8D93E695@pb1.pair.com>
References: <64.32.02884.7983D695@pb1.pair.com> <CAPhkiZy1Xo4mj758mtjcMGnX2PV0VsiHa9uN_Ka=1xiiXAx7Mg@mail.gmail.com>
 <86.8B.02884.8D93E695@pb1.pair.com>
Date: Tue, 18 Jul 2017 19:20:29 +0200
Message-ID: <CABdc3Wq3foNPTY_3_qEJ_E2naFZ9d9s9BXA_iPCiGNNt_GE+xg@mail.gmail.com>
To: Andreas Treichel <gmblar@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c1b45026b20a805549abb32"
Subject: Re: [PHP-DEV] http_cookie_set and http_cookie_remove
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c1b45026b20a805549abb32
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Andreas,

2017-07-18 18:39 GMT+02:00 Andreas Treichel <gmblar@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,
--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--94eb2c1b45026b20a805549abb32--