Re: [PHP-DEV] Partitioned cookies
Hi On 24/12/2023 17:04, Derick Rethans wrote: > On 24 December 2023 12:46:40 CET, Niels Dossche > wrote: >> Hi internals >> >> I opened a PR [1] to implement Partitioned cookie support, as requested on >> the bugtracker [2], into the setcookie() PHP function. This is done by >> adding an option to the $options array, not via an additional argument to >> the function. The amount of code to support this is tiny. >> >> This cookie option is being pushed by browser vendors (primarily by Google >> it seems) to eliminate third-party cookies [3, 4]. One of the impacts here >> is that cookies marked with "SameSite=None; Secured" without "Partitioned" >> will stop working eventually during 2024. >> >> Although the Partitioned cookie proposal is still a draft, Chrome will apply >> the change starting in January 2024 for a tiny percentage of users (as a >> form of A/B testing it seems). Symfony has already implemented support for >> this option as well [5]. >> The SameSite option was also added in PHP when it was still in a draft. >> >> Let me know what you think and if you are okay / objecting to merging this >> PR. > > > I've two concerns (none with the PR, as I haven't checked): > > - Compatibility: > https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies#browser_compatibility Right, indeed it is only supported by Blink-based browsers right now. It is on the roadmap for Safari and Firefox for 2024 according to https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/ > - What happens if it just stays a draft, or doesn't get accepted, or with a > different name? Good question, no idea. > > And also, would/should the PHP function enforce that this should only be set > if for example Secure is set too? And if so, with a warning or TypeError? This constraint is enforced already in the PR. If you try to set it without setting Secure, a ValueError is thrown. This is consistent with how other options can also throw a ValueError if constraints are broken. > > cheers > Derick Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Sat, Dec 23, 2023 at 12:34 PM Kévin Dunglas wrote: > Hello and Merry Christmas! > > One of the main features of FrankenPHP is its worker mode, which lets you > keep a PHP application in memory to handle multiple HTTP requests. > > Worker modes are becoming increasingly popular in the PHP world. Symfony > (Runtime Component), Laravel (Octane), and many projects based on these > frameworks (API Platform, Sulu...) now support a worker mode. > > In addition to FrankenPHP, projects such as RoadRunner and Swoole provide > engines supporting worker modes. > > According to benchmarks, worker modes can improve the performance of PHP > applications by up to 15 times. > In addition to FrankenPHP, which is basically a SAPI for Go's integrated > web server, a new generation of SAPIs is currently under development. > Several SAPIs written in Rust (including one by the RoadRunner team) are > currently under development. > > These SAPIs, along with existing SAPIs, could benefit from a shared > infrastructure to build worker modes. > > > > The FrankenPHP code is written and should be easy to move around in PHP > itself, to enable other SAPIs to use it. > > In addition to sharing code, maintenance, performance optimization, etc., > the existence of a common infrastructure would standardize the way worker > scripts are created and provide a high-level PHP API for writing worker > scripts that work with all SAPIs that rely on this new feature. > > SAPIs will still have to handle fetching requests from the web server and > pausing the worker to wait for new requests (in FrankenPHP, we use > GoRoutines for this, in Rust or C, other primitives will have to be used), > but almost everything else could be shared. > > For reference, here's the FrankenPHP code I propose to integrate into > libphp: https://github.com/dunglas/frankenphp/blob/main/frankenphp.c#L245 > > The public API is documented here: > https://frankenphp.dev/docs/worker/#custom-apps > > I'd like to hear what the community thinks about this. Would you be > interested in this functionality in PHP? Should I work on an RFC? > > If there's interest, I can work on a patch. > > Cheers, > -- > Kévin Dunglas > Much like Larry, I'm curious what sort of scope you imagine for this. Are you imagining something that is geared specifically towards HTTP requests, or would this be a more generic "PHP Application Worker" that might be spawned to handle other types of applications? Could we have a worker listen to a specific port and respond to or handle all requests on that port/device? Jordan
Re: [PHP-DEV] Partitioned cookies
On 24 December 2023 12:46:40 CET, Niels Dossche wrote: >Hi internals > >I opened a PR [1] to implement Partitioned cookie support, as requested on the >bugtracker [2], into the setcookie() PHP function. This is done by adding an >option to the $options array, not via an additional argument to the function. >The amount of code to support this is tiny. > >This cookie option is being pushed by browser vendors (primarily by Google it >seems) to eliminate third-party cookies [3, 4]. One of the impacts here is >that cookies marked with "SameSite=None; Secured" without "Partitioned" will >stop working eventually during 2024. > >Although the Partitioned cookie proposal is still a draft, Chrome will apply >the change starting in January 2024 for a tiny percentage of users (as a form >of A/B testing it seems). Symfony has already implemented support for this >option as well [5]. >The SameSite option was also added in PHP when it was still in a draft. > >Let me know what you think and if you are okay / objecting to merging this PR. I've two concerns (none with the PR, as I haven't checked): - Compatibility: https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies#browser_compatibility - What happens if it just stays a draft, or doesn't get accepted, or with a different name? And also, would/should the PHP function enforce that this should only be set if for example Secure is set too? And if so, with a warning or TypeError? cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
On Sat, Dec 23, 2023, at 2:34 PM, Kévin Dunglas wrote: > Hello and Merry Christmas! > > One of the main features of FrankenPHP is its worker mode, which lets you > keep a PHP application in memory to handle multiple HTTP requests. > > Worker modes are becoming increasingly popular in the PHP world. Symfony > (Runtime Component), Laravel (Octane), and many projects based on these > frameworks (API Platform, Sulu...) now support a worker mode. > > In addition to FrankenPHP, projects such as RoadRunner and Swoole provide > engines supporting worker modes. > > According to benchmarks, worker modes can improve the performance of PHP > applications by up to 15 times. > In addition to FrankenPHP, which is basically a SAPI for Go's integrated > web server, a new generation of SAPIs is currently under development. > Several SAPIs written in Rust (including one by the RoadRunner team) are > currently under development. > > These SAPIs, along with existing SAPIs, could benefit from a shared > infrastructure to build worker modes. > > > > The FrankenPHP code is written and should be easy to move around in PHP > itself, to enable other SAPIs to use it. > > In addition to sharing code, maintenance, performance optimization, etc., > the existence of a common infrastructure would standardize the way worker > scripts are created and provide a high-level PHP API for writing worker > scripts that work with all SAPIs that rely on this new feature. > > SAPIs will still have to handle fetching requests from the web server and > pausing the worker to wait for new requests (in FrankenPHP, we use > GoRoutines for this, in Rust or C, other primitives will have to be used), > but almost everything else could be shared. > > For reference, here's the FrankenPHP code I propose to integrate into > libphp: https://github.com/dunglas/frankenphp/blob/main/frankenphp.c#L245 > > The public API is documented here: > https://frankenphp.dev/docs/worker/#custom-apps > > I'd like to hear what the community thinks about this. Would you be > interested in this functionality in PHP? Should I work on an RFC? > > If there's interest, I can work on a patch. > > Cheers, In concept, I love this and would be ecstatic to see it happen. In practice, I want to understand the implications for user-space code. Does this mean FPM could be configured in a way to execute a file like that shown in the docs page above? Or would it only work with third party SAPIs like FrankenPHP? I assume the handler function would be differently named. Is passing in super-globals the right/best way to handle each request, or would it be sensible to have some other abstraction there? (Whether a formal request object a la PSR-7 or something else.) To what extent would user-space code run this way have to think about concurrency, shared memory, persistent SQL connections, etc? Does it have any implications for fiber-using async code? Depending on the details, this could be like fibers but for 3rd party SAPIs (something about 4 people in the world actually care about directly, everyone else just uses Revolt, Amp, or React, but mostly it doesn't get used), or completely changing the way 90% of the market runs PHP, which means frameworks will likely adapt to use that model primarily or exclusively (ie, less of a need for a "compile" step as a generated container or dispatcher is just held in memory automatically already). The latter sounds exciting to me, but I'm not sure which is your intent, so I don't know if I'm going too far with it. :-) Please advise on what the implications would be for the non-SAPI-developing PHP devs out there. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Partitioned cookies
Hi internals I opened a PR [1] to implement Partitioned cookie support, as requested on the bugtracker [2], into the setcookie() PHP function. This is done by adding an option to the $options array, not via an additional argument to the function. The amount of code to support this is tiny. This cookie option is being pushed by browser vendors (primarily by Google it seems) to eliminate third-party cookies [3, 4]. One of the impacts here is that cookies marked with "SameSite=None; Secured" without "Partitioned" will stop working eventually during 2024. Although the Partitioned cookie proposal is still a draft, Chrome will apply the change starting in January 2024 for a tiny percentage of users (as a form of A/B testing it seems). Symfony has already implemented support for this option as well [5]. The SameSite option was also added in PHP when it was still in a draft. Let me know what you think and if you are okay / objecting to merging this PR. Kind regards Niels [1] https://github.com/php/php-src/pull/12652 [2] https://github.com/php/php-src/issues/12646 [3] https://developers.google.com/privacy-sandbox/3pcd [4] https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies [5] https://github.com/symfony/symfony/pull/52002 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
