--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6E0D42E3-F11E-4F8F-A58B-A2F9917469B5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
I'm really not a fan of interfacing __invoke and would like an actual method like handle() or process() instead.
The only upside of using __invoke is that you can pass a callback instead of an actual interface implementation and the result would still work.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdDOdeBfVH%3Dv59CRSHcaomMF1dCJOBXQmk7UxG54k_b1Bw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6L-S5L%2BWp1HRdD7P2Zu0kugwA50RT4hLy-MbfNku1NLHA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAKiSzdAT2DA6r%3DDf%2BrE7%3DzJXTJ%3D7HkFXCwaVzPAu6-DGQmZTkw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9B58747E-81C0-46AA-9D5D-7910AD58C820%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6KiuO5YP%2BBFPuiTn0nf-ZUhLXXmzCQGDaV_pmLONb%3Dp3w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/670CD860-73C0-4E15-AC5A-068B6EE17345%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6%2BdHFpWt9inCShO7s%3D%2Bk4Tf%3DKLasP2aWb1dZvqwwr1zaw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6ACB5BDB-0DB2-4366-9628-92E0FCBF2FB8%40gmail.com.
Exactly the problem I described earlier, there is only one invoke() and that limits you. While with normal methods you coukd have handleRequest and handleServerRequest() methods without conflict
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/vTtGxdIuBX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6ACB5BDB-0DB2-4366-9628-92E0FCBF2FB8%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv2oj08QJW01i_Kp2j9nvhT%3D6EMRTiADqTNWCo4NewE4Uw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6J8VJ0L3kSerzCJjezZwMwBM5iiC_Ytvzs3qGsNL%3DuKVQ%40mail.gmail.com.
It gas middleware embodied in processors. That allows for a declarative approach to request processing. Having separate methods allows both methids to be sarisfied and look coherently imo
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/vTtGxdIuBX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/F3F16BAB-120F-44E9-BBC5-BF0885BB65FA%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/F3F16BAB-120F-44E9-BBC5-BF0885BB65FA%40gmail.com.
About the initial proposal I don't see the point of adding an interface with _invoke(). When I'm using _invoke() it's to be able to pass a closure. But when I'm introducing an interface it's to type hint against it, which prevent me from using a Closure if I'm not using php 7.1 or an higher version...
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CANamvv2FrjUUfyeqJ8_WfG4mrR6KUs9tEvsqUgLb8Wz0tBpOmQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_g%3DMZL8ehRp%3DvSND-v7Q%2BYhY_zcgagPEZJ4tXLYtpchOA%40mail.gmail.com.
There is really no point in standardizing dispatchers since you dont expect one dispatcher to be portable with other framework/library. Even then it is possible for the dispatcher to just implement the middleware interface and wrap the middlewares inside it.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_i_OAJW_aJc1Tppn0pvqXAxk%3Djj6AOG4rivZ0YHgRd8oA%40mail.gmail.com.
I would suggest renaming the exception static method to 'requiredBy', to make more clear why the middleware is passed as an argument.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6J18Ayp7CVVv8g4HPM_tGjthyrLk%3DDp-cevCd2t47qNXg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f88533ba-71cc-4eff-97f9-e8d5186355b8%40googlegroups.com.
Apologies for the novel below.
@Woody Putting the off-the-cuff Etag example aside, the body is less of a problem than the headers. You can easily replace the body of a response but PSR-7 has no good way to replace all headers, short of deliberately omitting all of the ones you can think of.
Imagine this example instead: You're building a middleware that catches exceptions and renders an error page when one occurs. When there's no exceptions, you just return the received response. Easy, works great! :)
Except one day you're debugging a page, the request goes all the way to the app, some header gets set in the controller but then something happens and an exception is thrown. The error middleware catches it, changes the body to the error page and then returns the response. And then suddenly the error won't go away because the Cache-Control header the app set wasn't cleared by the Error middleware. Or it tries to download the error page because the Content-Disposition was set. Or it works fine locally but not in production because it remembered to remove max-age but not s-maxage.
There's all sorts of stuff like this that could be avoided by either a) resetting all headers or b) returning a new instance. As mentioned, PSR-7 doesn't have a good way to void all headers, it can only remove a specifically mentioned header, one at a time. Short of writing a white-list-copy method, it seems much easier to just return a new blank instance.
So, this isn't an issue that effects all (or even most) middleware but it really makes life hard for those that it does hit.
Still, there's resistance to allowing middleware to create new instances, mainly because (and I'm interpreting) folks are worried about middlewares including bloat via alternate PSR-7 implementations or having conflicting version requirements. As it stands, there are three proposals to fix this:
1) We just allow them to include these alternate implementations. It's all the same interface and there's only a handful of implementations on the market.
2) Michael Dowling suggests a ResponseFactory that can be injected via constructor. This is a really good technical solution (though I'd recommend it include Request as well). My concern is that it will make the PSR seem more complex and we won't be able to teach folks to use it properly and they'll return new instances anyways.
3) Anthony Ferrera suggests a compromise: inject a blank/default response (or request) into the constructor. This is pretty simple, doesn't require any extra interfaces, plays well with their immutable nature and still lets folks configure everything by just using their DI containers. And it only effects those special middleware that need this. :)
Personally, I think #3 is a winner, both technically and in terms of a compromise that people can accept/teach. The constructor interfaces on the middleware will enforce good practice.
This might seem to render it a non-issue but there's still one underlying issue: We can't make anyone do this with their custom middleware. It is _really_ important that we recommend treating all PSR-7 implementations as equal and the dispatchers shouldn't count on getting the same concrete type back. It's just not enforceable with PHP's type system. If a dispatcher really needs its custom type, we should recommend they convert it back, never assume.
I can take or leave removing the Response parameter, that's not a huge deal to me, but treating the implementations as interchangable is really important.
One last thing and then I'll shut up. :) With regards to the client/server middleware and the trait accompanying it, I haven't seen much client middleware out there and I wonder if trying to capture that will make this PSR more complex (when it should be a really simple slam dunk).
What would folks think about moving Client middleware to a separate PSR and keep the scope here on just server middlewares, which have a clear, pressing need?
That would also seem to be a +1 for the named method argument, since we could release a method that typehints on ServerRequestInterface, then later release another PSR for client middleware. If your middleware supports both, cool, just implement two interfaces :) (There's a caveat here with the ServerRequest extending Request, but I have a couple ideas about that)
Taylor, your entire argument is couched in terms that only make sense with a single implementation of request/response. Stack PHP is very specific to Symfony. In the world of PSR-7, a middleware _will not know_ what the correct implementation is. A middleware would depend on the interfaces _only_ and not a specific vendor package.
I don't understand why you are arguing so hard against something that most adopters of PSR-7 have already agreed upon informally.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1ad1f451-fc4d-4ee0-94eb-82ae09be0444%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/79151E44-284D-4C3D-AFB1-562E57EC0E27%40gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/vTtGxdIuBX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/af84d550-da05-49c3-9e5a-7328e589fb50%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/84100215-0b30-430f-a50f-2a53be271d7c%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAARDrK9%3DEXfZT0mgOk33U%3DbNBwHKOSQxnXiPMDieqcSRm7a53Q%40mail.gmail.com.
Middleware that modifies a response could invoke `$next` and apply changes to the response returned. Closures can close over a response or response factory. These are both things that Guzzle's PSR-7 compliant middleware does frequently without requiring that an empty response be passed from middleware to middleware.
In other languages, the `(request, response, next): void` signature is used when a response is a vehicle for side effects (such as writing to a ResponseWriter in Go or to res.send in Express.js). You might also opt to use that signature if the response is a mutable "out parameter." That's not the case with PSR-7, where responses are immutable value objects that adhere to a well-defined interface.
In that case, you could simply return a response that the middleware creates (with `new`, by pulling one from a factory, by calling a `with*` method on a response that had been closed over or passed in via constructor).
On Wednesday, May 18, 2016 at 11:01:46 AM UTC-7, Woody Gilk wrote:On Wed, May 18, 2016 at 12:58 PM, Jonathan Eskew <jona...@jeskew.net> wrote:
> Middleware that modifies a response could invoke `$next` and apply changes
> to the response returned.
Not if they want to abort the request and stop processing further middleware.
--
Woody Gilk
http://about.me/shadowhand
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/517cc0c6-3b56-4f0e-aa7a-07dffdb44a76%40googlegroups.com.
An important consideration is that while double-pass style (passing a
request and a response all the way through the pipeline) may be the most
popular approach by number of distinct implementations right now, by
number of installations using it the lambda-style (request in, response
out) is far, FAR more widely used. Although Fabien has openly said he
doesn't like the middleware approach, the Symfony HttpKernelInterface is
now at the heart of dozens of projects (including several members
here)[1]. If we're looking to standardize middlewares we should not
ignore that, prior to the last 12 months, HttpKernelInterface was the de
facto PHP middleware architecture.
[1] http://symfony.com/components/HttpKernel
--Larry Garfield
On 05/11/2016 10:40 PM, Woody Gilk wrote:
> There is actually a simple way to remove all headers:
>
>
> $headers = array_keys($response->getHeaders());
>
> foreach ($headers as $header) {
> $response = $response->withoutHeader($header);
> }
>
>
> This might not be the most elegant thing ever, but it is simple
> enough. There are also other user-land ways to create an entirely
> clean Response object. Basically, I don't think there is a strong
> enough argument or enough real-world examples to make this a valid
> concern.
>
> As per your example of an error being cached, normally a Cache-Control
> header would be set on output as part of a middleware. By this point,
> the entire request would have successfully executed and the only place
> an exception could be occurring would be in middleware itself. While
> this may be a remote possibility, the likelihood in a production
> application seems very remote to me.
>
> There is also nothing in the current proposal that prevents having a
> RequestFactory or ResponseFactory injected into middleware that needs
> it. If there was such a need, it could be done as:
>
>
> if ($this->whateverCondition($request, $response)) {
> $response = $this->responseFactory->make();
> }
>
> // ... keep calm and carry on
>
>
> Again, I think the current proposal does not need to address this
> scenario because it is an edge case that can be addressed as necessary
> in specific implementations.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
>
> On Wed, May 11, 2016 at 3:28 PM, Ross Tuck <m...@rosstuck.com> wrote:
>> Apologies for the novel below.
>>
>>
>> @Woody Putting the off-the-cuff Etag example aside, the body is less of a
>> problem than the headers. You can easily replace the body of a response but
>> PSR-7 has no good way to replace all headers, short of deliberately omitting
>> all of the ones you can think of.
>>
>>
>> Imagine this example instead: You're building a middleware that catches
>> exceptions and renders an error page when one occurs. When there's no
>> exceptions, you just return the received response. Easy, works great! :)
>>
>>
>> Except one day you're debugging a page, the request goes all the way to the
>> app, some header gets set in the controller but then something happens and
>> an exception is thrown. The error middleware catches it, changes the body to
>> the error page and then returns the response. And then suddenly the error
>> won't go away because the Cache-Control header the app set wasn't cleared by
>> the Error middleware. Or it tries to download the error page because the
>> Content-Disposition was set. Or it works fine locally but not in production
>> because it remembered to remove max-age but not s-maxage.
>>
>>
>> There's all sorts of stuff like this that could be avoided by either a)
>> resetting all headers or b) returning a new instance. As mentioned, PSR-7
>> doesn't have a good way to void all headers, it can only remove a
>> specifically mentioned header, one at a time. Short of writing a
>> white-list-copy method, it seems much easier to just return a new blank
>> instance.
>>
>>
>> So, this isn't an issue that effects all (or even most) middleware but it
>> really makes life hard for those that it does hit.
>>
>>
>> Still, there's resistance to allowing middleware to create new instances,
>> mainly because (and I'm interpreting) folks are worried about middlewares
>> including bloat via alternate PSR-7 implementations or having conflicting
>> version requirements. As it stands, there are three proposals to fix this:
>>
>>
>> 1) We just allow them to include these alternate implementations. It's all
>> the same interface and there's only a handful of implementations on the
>> market.
>>
>> 2) Michael Dowling suggests a ResponseFactory that can be injected via
>> constructor. This is a really good technical solution (though I'd recommend
>> it include Request as well). My concern is that it will make the PSR seem
>> more complex and we won't be able to teach folks to use it properly and
>> they'll return new instances anyways.
>>
>> 3) Anthony Ferrera suggests a compromise: inject a blank/default response
>> (or request) into the constructor. This is pretty simple, doesn't require
>> any extra interfaces, plays well with their immutable nature and still lets
>> folks configure everything by just using their DI containers. And it only
>> effects those special middleware that need this. :)
>>
>>
>> Personally, I think #3 is a winner, both technically and in terms of a
>> compromise that people can accept/teach. The constructor interfaces on the
>> middleware will enforce good practice.
>>
>>
>> This might seem to render it a non-issue but there's still one underlying
>> issue: We can't make anyone do this with their custom middleware. It is
>> _really_ important that we recommend treating all PSR-7 implementations as
>> equal and the dispatchers shouldn't count on getting the same concrete type
>> back. It's just not enforceable with PHP's type system. If a dispatcher
>> really needs its custom type, we should recommend they convert it back,
>> never assume.
>>
>>
>> I can take or leave removing the Response parameter, that's not a huge deal
>> to me, but treating the implementations as interchangable is really
>> important.
>>
>>
>> One last thing and then I'll shut up. :) With regards to the client/server
>> middleware and the trait accompanying it, I haven't seen much client
>> middleware out there and I wonder if trying to capture that will make this
>> PSR more complex (when it should be a really simple slam dunk).
>>
>>
>> What would folks think about moving Client middleware to a separate PSR and
>> keep the scope here on just server middlewares, which have a clear, pressing
>> need?
>>
>>
>> That would also seem to be a +1 for the named method argument, since we
>> could release a method that typehints on ServerRequestInterface, then later
>> release another PSR for client middleware. If your middleware supports both,
>> cool, just implement two interfaces :) (There's a caveat here with the
>> ServerRequest extending Request, but I have a couple ideas about that)
>>
>>
>> On Wednesday, May 11, 2016 at 5:43:21 PM UTC+2, Korvin Szanto wrote:
>>> I worked on my own middleware enabled psr-7 request handler for awhile and
>>> I went through all these oscillations we are talking about here. I'm typing
>>> this up on a phone so bear with me.
>>>
>>> Firstly I ran into the attribute issue and asked around and it sounded
>>> like it was just an oversight. Another issue I ran into was the fact that
>>> there is no way to see if an uploaded file has been moved previously. We
>>> throw an ambiguous exception when the file has been previously moved and
>>> it's as far as I am aware impossible to properly handle the error case.
>>> Perhaps this is a good argument for a new psr-7 updated replacement.
>>>
>>> On __invoke vs a properly named handler method, the reason I opted for a
>>> named handler method in the beginning is because it felt more natural to
>>> have my dispatcher typehint on my middleware interface rather than hinting
>>> on callable. I eventually conceded to using __invoke and hinting on callable
>>> due to pressure from other implementations. Because of this, I just opted to
>>> hint on callable and use closures instead of a real interface implementation
>>> [1].
>>> See my dispatcher [2] which uses my overly complex pipeline [3] to send
>>> the request and response through a stack of middleware.
>>>
>>> I recognize that it's more flexible but it really does feel wrong to me
>>> for reasons I cannot articulate. I honestly would much rather we have a
>>> named method for handling instead of using the magic method.
>>>
>>> I 100% agree that both request and response need to be passed into the
>>> handler method. Passing in both allows you to choose whether you will return
>>> a new instance or will modify the running instance. Simply using a factory
>>> method or creating a new response every time just doesn't do it in my
>>> opinion. Though those options are still available if the response is passed
>>> in.
>>>
>>> [1]
>>> https://github.com/Buttress/framework/blob/master/test/Test/Http/RequestHandlerTest.php
>>> [2] https://github.com/Buttress/Http/blob/master/RequestHandler.php
>>> [3] https://github.com/Buttress/Pipeline/blob/master/Pipeline.php
>>>
>>> Thank you everyone for the discussion, it's a much needed distraction.
>>> Korvin
>>>
>>>
>>>
>>> On Tue, May 10, 2016 at 2:03 PM Marco Perone <pasa...@gmail.com> wrote:
>>>> Consider the following case, using the signature you are suggesting
>>>>
>>>> public function __invoke(Request $request, callable $next)
>>>> {
>>>> if ($this->goOn()) {
>>>> return $next($request);
>>>> }
>>>>
>>>> // return a default Response
>>>> return new MyResponseImplementation();
>>>> }
>>>>
>>>> If I don't have a $request passed in as a method argument, I must depend
>>>> on a concrete implementation of the ResponseInterface.
>>>>
>>>> On the other hand, if a $response is passed in as an argument, I have a
>>>> prototypical Response I can modify, not relying on any concrete
>>>> implementation.
>>>>
>>>>
>>>> On Tuesday, May 10, 2016 at 10:19:14 PM UTC+2, Ross Tuck wrote:
>>>>> With respect, I'm not sure Dependency Inversion is a complete reason to
>>>>> inject the response here.
>>>>>
>>>>> Even if we do inject the Response, they're essentially value objects in
>>>>> the HTTP scope and it would be exceedingly common for someone to just return
>>>>> a different instance, rather than modify the instance passed in. I'd go so
>>>>> far as to call this a feature for many use cases: if I'm writing an ETag
>>>>> middleware and want to return a cache hit, I don't want to manually truncate
>>>>> the body and clear other headers off when it would be easier to just return
>>>>> a new response and to my knowledge, PSR-7 doesn't have a
>>>>> "createBlankInstance" factory method.
>>>>>
>>>>> Considering how easy (and occasionally reasonable) it is to return a new
>>>>> instance within any given middleware, I don't think including a response
>>>>> provides _any_ guarantee about the return value and we should bake that
>>>>> assumption into the spec recommendations from the outset, lest we end up
>>>>> with a bunch of soft dependencies or LSP violatons. if a
>>>>> dispatcher/framework needs a particular type of object internally, it would
>>>>> be better to convert to/from PSR-7 objects before/after the middleware
>>>>> dispatcher cycle, rather than assume it's going to get the same type at the
>>>>> end. "My\Special\Response::fromPsr7Response($response);"
>>>>>
>>>>> Just my 2 cents, tapping out for the night. :)
>>>>>
>>>>> On Tuesday, May 10, 2016 at 9:46:46 PM UTC+2, Woody Gilk wrote:
>>>>>> On Tue, May 10, 2016 at 2:36 PM, Ross Tuck <m...@rosstuck.com> wrote:
>>>>>>> why do we have the Response added in as a parameter? Why can't it be
>>>>>>> solely
>>>>>>> a return value?
>>>>>> I can answer this very simply: Dependency inversion does not allow it.
>>>>>>
>>>>>> If your middleware is only ever type hinted against PSR-7
>>>>>> request/response interfaces (as it should be) then by what mechanism
>>>>>> do you create a response? How do you know what vendor is going to
>>>>>> provide the expected implementation? How do you instantiate the
>>>>>> response class correctly?
>>>>>>
>>>>>> The short answer is that you don't and you shouldn't. The correct
>>>>>> thing to do is invert the dependencies and create the request and
>>>>>> response objects early on in application execution and pass them
>>>>>> through the stack:
>>>>>>
>>>>>> dispatch(request, response) : response
>>>>>>
>>>>>> In this way, you can be reasonably sure that the final response is
>>>>>> going to be the same implementation (but most likely not the same
>>>>>> instance, due to immutability) as the response that was initialized
>>>>>> early on.
>>>>>>
>>>>>> --
>>>>>> Woody Gilk
>>>>>> http://about.me/shadowhand
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "PHP Framework Interoperability Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to php-fig+u...@googlegroups.com.
>>>> To post to this group, send email to php...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> For more options, visit https://groups.google.com/d/optout.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to php-fig+u...@googlegroups.com.
>> To post to this group, send email to php...@googlegroups.com.
>> To view this discussion on the web visit
>> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/573C3297.6040505%40garfieldtech.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_jpGONkTkYQS5OXuD3%2B0V8hsFVJ6LGmTQ9QKci4fFZsbA%40mail.gmail.com.
The application should not create the response. The application should
not care what implementation of PSR-7 is used. The choice of
implementation belongs completely outside of the application, in the
front matter.