Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
PSR-7 is here, and is being adopted in droves. Zend Framework 3 will be based on it, Symfony 2.7 includes support for it, Guzzle 6 is based on it, the Slim framework is planning to adopt it... It's rapidly a thing, and Drupal 8 should be on that list.
Proposed resolution
There are a number of steps we can take, listed below. They all boil down to enabling, but not requiring, module developers to use PSR-7 classes as freely as possible wiht as little effort as possible. Symfony has now done the major initial work for us with a new conversion library.
http://symfony.com/blog/psr-7-support-in-symfony-is-here
I am also tagging this for framework manager review. As subsystem maintainer I believe this is worth doing at this point, as:
- It should not be disruptive to any other active patches.
- There should be no API breakage that I can foresee.
- It is part of keeping up with Symfony's request/response behavior, which we're trying to do.
- Officially supporting PSR-7 is good positioning for Drupal, especially as many projects are already jumping on that bandwagon. (Symfony, Zend, Slim, Guzzle, just to name a few.) Even if our normal request/response flow remains Symfony HttpFoundation for the foreseeable future this gives us flexibility and keeps Drupal state-of-the-art.
But if this work is not done by RC then it should not block release. Anything remaining can be done in 8.1 safely as there's no API breakage. Framework managers please confirm if you agree.
Remaining tasks
- Get #2470693: Upgrade to Symfony 2.7.0 commited. As I write this it is RTBC so that should happen pretty quickly.
- #2497691: Include Symfony PSR-7 bridge library Assigned to: alexpott
- #2497697: PSR-7 support for ControllerResolver
- #2497693: Add PSR-7 to Symfony Response View listener
- #2497699: PSR-7 middleware support
Anything else that can/should be done here?
API changes
There should be no API breakage. Everything here is an addition.
Beta phase evaluation
| Issue category | Task because nothing is broken per se so it's not a bug, but not an entirely new feature as PSR-7 is a natural extension of our Symfony and broader PHP integration. |
|---|---|
| Issue priority | Major because it's not release blocking (thus not critical) but strategically important for Drupal |
| Disruption | None. There should be no API breakage from this issue, and the overlap of the patches here with work elsewhere is, as far as I'm aware, minimal to none. |
Comments
Comment #1
larowlan"Its not written" === we should contribute
Comment #2
Crell commentedlarowlan: Once they post a roadmap, and StackPHP figures out what they're doing, YES YES YES!
Comment #3
Crell commentedWell, that escalated quickly:
http://symfony.com/blog/psr-7-support-in-symfony-is-here
Step one is to get #2470693: Upgrade to Symfony 2.7.0 commited. As I write this it is RTBC so that should happen pretty quickly.
Step two is to get the new libraries added: #2497691: Include Symfony PSR-7 bridge library
Step three is to enhance our ControllerResolver to be able to pass a PSR7 Request object instead of a Symfony Request object if a controller asks for it, as Symfony now does. See #2497697: PSR-7 support for ControllerResolver
step four is to allow controllers to return PSR-7 responses: #2497693: Add PSR-7 to Symfony Response View listener - easy peasy
Any additional things we can/should do here that would not break anything?
I am also tagging this for framework manager review. As subsystem maintainer I believe this is worth doing at this point, as:
1) It should not be disruptive to any other active patches.
2) There should be no API breakage that I can foresee.
3) It is part of keeping up with Symfony's request/response behavior, which we're trying to do.
4) Officially supporting PSR-7 is good positioning for Drupal, especially as many projects are already jumping on that bandwagon. (Symfony, Zend, Slim, Guzzle, just to name a few.) Even if our normal request/response flow remains Symfony HttpFoundation for the foreseeable future this gives us flexibility and keeps Drupal state-of-the-art.
But if not in by RC then it should not block release. Framework managers please confirm if you agree.
Comment #4
Crell commentedRecataloging this issue into a meta and updating IS.
Comment #5
Crell commentedI am willing to work on these as soon as they're approved.
Comment #6
dawehner:( feared that this happened at some point.
Comment #7
webchickI'm a bit confused why we would be doing this now and not in 8.1.0. This is a new capability (aka, "feature"), is it not?
Comment #8
dawehnerI think PHP community wise it would be a great sign to show that we adapt new standards in major releases.
Comment #9
Crell commented#8 is essentially correct. From a technical perspective I believe this is safe to do in 8.1. From a strategic perspective I believe it is valuable for us to be among the early adopters of PSR-7, and continue position ourselves as a forward-looking platform. The very small impact on the rest of the system (aside from the changes to the ControllerResolver, which is quite stable right now, I don't think there's any other touchpoints that would matter) so the chances of it delaying release or slowing down critical issues is practically nil.
Comment #10
yched commentedPSR-7 sounds very promising in terms of ecosystem interoperability, would be awesome to have D8 support it out of the box.
But what about the symfony bridge requiring the zend-diactoros implementation, which itself requires PHP 5.5 ? We only require 5.4.5 atm.
Comment #11
Crell commentedyched: Already mentioned in #2497691: Include Symfony PSR-7 bridge library, and I've reached out to the Zend folks to lower the requirement. The lib only needs 5.4; the 5.5 requirement was just perfunctory. Either we raise our requirement (which may already happen, see #2296557: [policy] Require PHP 5.5) or they lower it (which I'm nudging them to do).
Comment #12
dawehnerhttps://github.com/zendframework/zend-stratigility is a possible middleware framework implementation
Comment #13
yched commentedIt's a bit sad that, after #2493911: Update guzzle, goutte and mink-goutte-driver to the latest release, we now ship with two separate PSR7 implementations ? (diactoros for the Symfony bridge, Guzzle PSR7 for Guzzle)
It seems symfony/psr-http-message-bridge only "suggests" zendframework/zend-diactoros. Is there any chance we could swap guzzlehttp/psr7 instead for the symfony bridge ?
(although, hm, guzzlehttp/psr7 states it currently lacks implementations for Psr\Http\Message\ServerRequestInterface &
Psr\Http\Message\UploadedFileInterface in its 1.0.0 and is open to PRs)
Comment #14
Crell commentedGuzzle's PSR-7 implementation serves a different purpose. It's optimized for client usage, while Diactoros is optimized for server usage. The fact that both can use the same interface, though, is exactly the point. It means any other code that wants to operate on "a request" or "a response" doesn't need to care which one it is.
Comment #15
jhedstromAdded #2546272: Update guzzlehttp/psr7 to 1.2.0 and guzzlehttp/promises to 1.0.2.
Comment #16
Crell commentedThe main parts are all in. Yay! The middleware thread is postponed to 8.1, which is fine. This still brings us up to parity with Symfony 2.7, which is sufficient for D8.
I'm not sure if we should mark this fixed or not since there's still a single child. Maybe fixed since the child can now stand alone?
Comment #17
Crell commentedDiscussed with xjm. This is closable. Yay!
Comment #19
xjmComment #20
andypostWhat to do with remaining issue #2497699: PSR-7 middleware support
It's last (5) bullet in summary and still open