Hi,
i want some feedback, about the following idea before i write a rfc.
Problem:
The functions setcookie and setrawcookie has many parameters. Most of
them are optional and extensions (e.g. same-site) make it even more messy.
The functions setcookie and setrawcookie has 8 parameters.
bool setcookie ( string $name [, string $value = "" [, int $expire = 0
[, string $path = "" [, string $domain = "" [, bool $secure = false [,
bool $httponly = false ]]]]]] )
bool setrawcookie ( string $name [, string $value [, int $expire = 0 [,
string $path [, string $domain [, bool $secure = false [, bool $httponly
= false ]]]]]] )
With the changes from https://wiki.php.net/rfc/same-site-cookie the
functions setcookie and setrawcookie even has 9 parameters.
bool setcookie ( string $name [, string $value = "" [, int $expire = 0
[, string $path = "" [, string $domain = "" [, bool $secure = false [,
bool $httponly = false [, string $samesite = "" ]]]]]]] )
bool setrawcookie ( string $name [, string $value [, int $expire = 0 [,
string $path [, string $domain [, bool $secure = false [, bool $httponly
= false [, string $samesite = "" ] ]]]]]] )
How to change this?
Add two new functions http_cookie_set and http_cookie_remove.
bool http_cookie_set(string $name, string $value [, array $options])
$options are equal to the optional parameters of setcookie and setrawcookie.
$options may contain:
expires: int
path: string
domain: string
secure: bool
httponly: bool
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
Example:
Set cookie with httponly and skip all other options.
http_cookie_add('foo', 'bar', [
'httponly' => true
]);
This is identical to, but much less readable:
setcookie('foo', 'bar', 0, '', '', false, true);
Full example with all options:
http_cookie_set('foo', 'bar', [
'expires' => time() + 3600,
'path' => '/',
'domain => 'www.example.com',
'secure' => true,
'httponly' => true,
'encode' => HTTP_COOKIE_ENCODE_RFC1738
]);
bool http_cookie_remove(string $name)
Why http_cookie_remove?
I do not find it self explanatory that setcookie('foo', "") or
setcookie('foo', NULL) delete a cookie.
Hi,
i want some feedback, about the following idea before i write a rfc.
... Most of them
are optional and extensions (e.g. same-site) make it even more messy.
Two thoughts:
i) Cookie functions are easily done in userland.
ii) Adding more stuff to an already complicated thing isn't the way to
make it simple.
Or, to repeat myself: http://news.php.net/php.internals/90940
The problem is that you're trying to build on a foundation of sand.
The session handling works but is incredibly fragile.Or to put it more colloquially this is a "how to get to Dublin
problem". To get to having a more secure and reliable session
handling, we need to start from some where else, not just keep
building on top of the current session handler code.To me, there are two good ways to proceed:
i) Develop a new session extension, that doesn't depend on magic
behaviour of globals and leave the current session handler as it is.
The new session extension could be shipped as a 'work in progress' when
it's good enough, before PHP 8. Then when it's stable, we could figure
out how to transition users from the old extension.
ii) Develop a session handler in userland code only. PHP is powerful
enough to support this. Although obviously there are big benefits to
shipping a session handler with PHP, I don't see any need for it to be
done internally other than we don't currently have a way of shipping
userland code with an extension. I'm hoping that before PHP 8, the
ability to ship PHP code as part of extensions would be in place.
cheers
Dan
Ack
Hi Dan,
Hi,
i want some feedback, about the following idea before i write a rfc.
... Most of them
are optional and extensions (e.g. same-site) make it even more messy.Two thoughts:
i) Cookie functions are easily done in userland.
It's not that easy for somebody unfamiliar with RFC 6265, and in my
observations that's most people.
ii) Adding more stuff to an already complicated thing isn't the way to
make it simple.Or, to repeat myself: http://news.php.net/php.internals/90940
The problem is that you're trying to build on a foundation of sand.
The session handling works but is incredibly fragile.Or to put it more colloquially this is a "how to get to Dublin
problem". To get to having a more secure and reliable session
handling, we need to start from some where else, not just keep
building on top of the current session handler code.To me, there are two good ways to proceed:
i) Develop a new session extension, that doesn't depend on magic
behaviour of globals and leave the current session handler as it is.
The new session extension could be shipped as a 'work in progress' when
it's good enough, before PHP 8. Then when it's stable, we could figure
out how to transition users from the old extension.ii) Develop a session handler in userland code only. PHP is powerful
enough to support this. Although obviously there are big benefits to
shipping a session handler with PHP, I don't see any need for it to be
done internally other than we don't currently have a way of shipping
userland code with an extension. I'm hoping that before PHP 8, the
ability to ship PHP code as part of extensions would be in place.
I don't get this ... new functions are being proposed, not modifying
the already existing ones - this is one of the good ways you've
listed.
Cheers,
Andrey.
Hi,
i want some feedback, about the following idea before i write a rfc.
... Most of them
are optional and extensions (e.g. same-site) make it even more messy.Two thoughts:
i) Cookie functions are easily done in userland.
ii) Adding more stuff to an already complicated thing isn't the way to
make it simple.Or, to repeat myself: http://news.php.net/php.internals/90940
The problem is that you're trying to build on a foundation of sand.
The session handling works but is incredibly fragile.
I'm not sure why you're quoting that here; cookies and sessions are very different things, and there's no intrinsic reason why a cookie API needs to be complicated (even if the HTTP and JS ones are really horrible).
I really like the sound of the proposal, including the separate remove function - the HTTP specs may be stuck with the awkward implementation of "delete by expiry", but there's no reason not to wrap that in something more meaningful to the user.
Regards,
--
Rowan Collins
[IMSoP]
Hi Andreas,
Hi,
i want some feedback, about the following idea before i write a rfc.
Problem:
The functions setcookie and setrawcookie has many parameters. Most of them
are optional and extensions (e.g. same-site) make it even more messy.The functions setcookie and setrawcookie has 8 parameters.
...
With the changes from https://wiki.php.net/rfc/same-site-cookie the
functions setcookie and setrawcookie even has 9 parameters....
How to change this?
Add two new functions http_cookie_set and http_cookie_remove.
I think you are right on the money with this in general, but there's 3
things I would change:
bool http_cookie_set(string $name, string $value [, array $options])
$options are equal to the optional parameters of setcookie and setrawcookie.
$options may contain:expires: int
path: string
domain: string
secure: bool
httponly: bool
- The wording here implies that these are the only attributes
allowed. In the interest of forward-compatibility, I'd allow arbitrary
attributes as well.
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
- I don't think this is necessary, nor that it belongs in the $options array.
Anybody who'd use it, would have to read RFC1738 and/or RFC3986 to
know what they do.
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.
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
bool http_cookie_remove(string $name)
Why http_cookie_remove?
I do not find it self explanatory that setcookie('foo', "") or
setcookie('foo', NULL) delete a cookie.
- http_cookie_remove() is an extra feature that you're bundling, but
has nothing to do with solving the original issue.
It MAY be something that people would want, but it also may not be,
and that makes it a contentions part of your would-be RFC.
There's certainly the possibility that some would vote against your
proposal entirely because of this ... just leave that for a future RFC
if this one passes.
That being said, again - I love the idea and would even like to work
with you on the RFC if you need any help.
Cheers,
Andrey.
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
- 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
- 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().
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
- 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
- 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
currentsetcookie(). 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_RFC1738And 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.1http_cookie_set() use the same encoding per default as
setcookie().--
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
Hi Michał,
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
http_response_code()- Get or Set the HTTP response code - which is THE
ONLY ONE function prefixed this way
This might be one of my next RFCs if my first RFC is well received.
Hi Andreas,
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
- 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
- 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
currentsetcookie(). 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_RFC1738And 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.1http_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.
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.
Hi Andreas,
On Tue, Jul 18, 2017 at 7:39 PM, Andreas Treichel gmblar@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
- 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
- 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
currentsetcookie(). 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_RFC1738And 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.1http_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 intosetcookie().But if we want an array-based
setcookie()alternative without changing
anything else, we can just changesetcookie()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.
Am 18.07.2017 um 20:39 schrieb Michael Morris:
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
but why do you do this?
looks like these days everybody is using fat frameworks for anything
like in JavaScript most people think Jquery is JavaScript
i must have done something right starting my own cms/framework
development in 2003 where a typical request takes 0.0015 to 0.0025
seconds on a 7 years old desktop machine without any 3rd party code
and where you can simply count the function calls of a core system until
large modules come into play
hence a guest hosting some hundret instances shows 100-500 Mhz on the
vCenter server and literally you can push out at best 50% of the
requests the machine could ansser to a internet connection because of
the additional latencys
Am 18.07.2017 um 20:56 schrieb lists@rhsoft.net:
Am 18.07.2017 um 20:39 schrieb Michael Morris:
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
solutionbut why do you do this?
looks like these days everybody is using fat frameworks for anything
like in JavaScript most people think Jquery is JavaScripti must have done something right starting my own cms/framework
development in 2003 where a typical request takes 0.0015 to 0.0025
seconds on a 7 years old desktop machine without any 3rd party code
and where you can simply count the function calls of a core system until
large modules come into playhence a guest hosting some hundret instances shows 100-500 Mhz on the
vCenter server and literally you can push out at best 50% of the
requests the machine could ansser to a internet connection because of
the additional latencys
and no, that "ab" output is not faked
in that case: Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz
a Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz makes 4300/second
Concurrency Level: 250
Time taken for tests: 63.577 seconds
Complete requests: 500000
Failed requests: 0
Keep-Alive requests: 496820
Total transferred: 2092609799 bytes
HTML transferred: 1888721877 bytes
Requests per second: 7864.46 [#/sec] (mean)
Time per request: 31.789 [ms] (mean)
Time per request: 0.127 [ms] (mean, across all concurrent requests)
Transfer rate: 32143.07 [Kbytes/sec] received
Am 18.07.2017 um 20:39 schrieb Michael Morris:
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
solutionbut why do you do this?
Because I want to be done in a matter of hours or at most days instead of a
matter of weeks or months. I've been down the "roll your own" road many
times. It usually isn't worth it.
Hi Michael,
2017-07-18 21:02 GMT+02:00 Michael Morris tendoaki@gmail.com:
On Tue, Jul 18, 2017 at 2:56 PM, lists@rhsoft.net lists@rhsoft.net
wrote:Am 18.07.2017 um 20:39 schrieb Michael Morris:
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
solutionbut why do you do this?
Because I want to be done in a matter of hours or at most days instead of a
matter of weeks or months. I've been down the "roll your own" road many
times. It usually isn't worth it.
You can do what you want, but personally, I think introducing this little
feature and cleaning some std API
is better than providing a more complex way of handling requests like
linked PSR-7 not everyone may want to use it.
There is always a way to use functional API in user-land PSR-7
implementation but not the other way.
IMHO if someone wants to use simple functional API let them use it, it may
also be used in more complex problem solutions.
--
regards / pozdrawiam,
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com
Am 18.07.2017 um 21:02 schrieb Michael Morris:
On Tue, Jul 18, 2017 at 2:56 PM, lists@rhsoft.net
mailto:lists@rhsoft.net <lists@rhsoft.net mailto:lists@rhsoft.net>
wrote:Am 18.07.2017 um 20:39 schrieb Michael Morris: 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/ <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 but why do you do this?Because I want to be done in a matter of hours or at most days instead
of a matter of weeks or months. I've been down the "roll your own" road
many times. It usually isn't worth it
it is when done right
it takes me 20 seonds to deplay updates on several hosts with hundrests
of instances - you just need to do it one time right
and no: it won't save you days or even hours when you wrap everything
in some framework call when a single native function line can do the
same with hundret times less costs
Am 18.07.2017 um 21:02 schrieb Michael Morris:
On Tue, Jul 18, 2017 at 2:56 PM, lists@rhsoft.net <mailto:
lists@rhsoft.net> <lists@rhsoft.net mailto:lists@rhsoft.net> wrote:Am 18.07.2017 um 20:39 schrieb Michael Morris: 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/ <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 inthe
language core then seeing something entirely new, especially a
band aid
solutionbut why do you do this?Because I want to be done in a matter of hours or at most days instead of
a matter of weeks or months. I've been down the "roll your own" road many
times. It usually isn't worth itit is when done right
Whatever Tony.
- Over the top claims, check.
- Condescending remarks, check.
- Superior attitude problem, check.
Yeah, I'm calling alt account. On the off chance you aren't Tony, you're
still the type of person I don't have time for in my life. To the block
list you go.
Hello Andrey,
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.
I think it is necessary to trigger a notice or warning for unknown
options for troubleshooting.
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 ...
The "attribute" expires (not expire) existing in the header Set-Cookie.
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().
I hope to meet your expectations.
But if we want an array-based
setcookie()alternative without changing
anything else, we can just changesetcookie()to accept arrays.
No this is just the only the first step for additional extensions.
Hello Andreas,
Hello Andrey,
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.I think it is necessary to trigger a notice or warning for unknown options
for troubleshooting.
I get that. However, that also means users have to wait for PHP
internals to discuss and vote on RFCs for each possible new cookie
attribute. Then wait for the release, and then the painfully slow
adoption rates.
And I'd also argue that the first thing one does while looking for
cookie-related issues is inspecting the response HTTP headers anyway,
so I don't think warnings would be that helpful.
Plus, this isn't something that can behave in unexpected ways; cookie
attributes have a clearly defined syntax.
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 ...The "attribute" expires (not expire) existing in the header Set-Cookie.
That's what I said ... ?
I was suggesting that the array keys be reserved for actual
attributes, not arbitrary PHP options.
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().I hope to meet your expectations.
But if we want an array-based
setcookie()alternative without changing
anything else, we can just changesetcookie()to accept arrays.No this is just the only the first step for additional extensions.
Care to elaborate?
You're not really addressing the concerns I'm raising, and now it
looks like you expect everybody to just trust you on this for the
promise of unknown goods in the future ... I'm sorry to say this, as I
want to help, but this is not a way to gather support.
Cheers,
Andrey.
Hi Andrey,
- The wording here implies that these are the only attributes
allowed. In the interest of forward-compatibility, I'd allow arbitrary
attributes as well.
I just try to implement something like this, to allow arbitrary
attributes. Is this what you prefer?
http_cookie_set('foobar', '1337', [
'foo' => 23,
'bar' => 42
]);
Set-Cookie: foobar=1337; foo=23; bar=42
HI,
Hi Andrey,
- The wording here implies that these are the only attributes
allowed. In the interest of forward-compatibility, I'd allow arbitrary
attributes as well.I just try to implement something like this, to allow arbitrary attributes.
Is this what you prefer?http_cookie_set('foobar', '1337', [
'foo' => 23,
'bar' => 42
]);Set-Cookie: foobar=1337; foo=23; bar=42
That is just what I had in mind, yes.
Cheers,
Andrey.