[REVIEW] PSR-7 HTTP Message Interface

[Beau Simensen]

The dust has settled on the last few revisions to PSR-7 and we are ready to move out of Draft stage. As the coordinator of this PSR, I hereby announce that as of 10:30PM UTC on Tuesday, February 17th, 2015, PSR-7 HTTP Message Interface has entered the Review stage.

Now is the time for members to get involved to help determine if this proposal is ready for an acceptance vote. If we decide to move forward with an acceptance vote, we can do so as early as 10:30PM UTC on Tuesday, March 3rd, 2015.

Of note from the Editor, the last notable change was to rename `*BodyParams` to `*ParsedBody` and to change the return value to null|array|object. For details on these specific changes, see the PR that introduced them.

https://github.com/php-fig/fig-standards/pull/429

[Richard Griffith]

In section 3.2.1, Psr\Http\Message\ServerRequestInterface, the expectation for the handling of a Content-Type of application/x-www-form-urlencoded in getParsedBody() is quite explicit. However, a Content-Type of multipart/form-data (as per RFC 2388) is not covered. While the coverage of the $_FILES aspect typical of this type is implied elsewhere in the standard, this type can carry other parameter data made available through the $_POST array, and handling of this data falls to an "otherwise" case, which "May" make it available. 

Is a defined behavior for this case intentionally omitted? Or perhaps the existing case definition is too narrow?

[Larry Garfield]

Hm, Good eye, Richard. I think we should require POST
multipart/form-data to result in a $_POST-alike parsed body, just like
form-urlencoded. Basically, in those situations where $_POST would
actually be useful, getParsedBody() should give it to you.

Can you submit a PR? It would be up to Beau to merge it now, or else
determine that such a change requires going back to draft mode. (I
don't think it does.)

--Larry Garfield

[Matthew Weier O'Phinney]

Just a follow-up: Richard DID submit pull requests to make this
clarification in both the fig-standards and http-message repos, and
those were merged today.

As noted: these changes do not change technical functionality of the
interfaces, but _do_ cover an expectation that is largely assumed
already. Implementations will need to ensure requests with
multipart/form-data Content-Type that contain key/value parts populate
the parsed body in the expected manner. POST requests in PHP do this
automatically, so most implementations will not see any changes;
however, I would assume that other request methods should emulate this
behavior via manual parsing. (I've done so in Apigility's
content-negotiation module, for instance.)

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Philip Sturgeon]

Don't forget to update the status here 

https://github.com/php-fig/fig-standards/blob/master/index.md

[Beau Simensen]

On Tuesday, February 24, 2015 at 7:36:55 AM UTC-6, Philip Sturgeon wrote:

Don't forget to update the status here 

https://github.com/php-fig/fig-standards/blob/master/index.md

Thanks. I had a PR out for a few days and it was merged this morning. 

[Jeremy Lindblom]

We (Guzzle / AWS SDK for PHP) are very excited about how the HTTP PSR has turned out and are currently building prototypes of our software with the PSR interfaces to explore what they mean to our projects and how we might use them going forward.

[Jeremy Lindblom]

Michael just published a WIP implementation of PSR7: https://github.com/guzzle/psr7. Please check it out and let us know what you think and if you have any suggestions.

On Tuesday, February 17, 2015 at 2:31:22 PM UTC-8, Beau Simensen wrote:

[Beau Simensen]

Michael posted his findings on URI encoding in another thread. If this is of interest to you, see that thread and discuss it there. If it is determined that we should address these issues, the Sponsors will decide if making this change constitutes a fundamental change (resulting in canceling review) or if it qualifies as a clarification (resulting in staying in review).

https://groups.google.com/d/msg/php-fig/917Eplnl-Dw/LiEHGlMlDE0J

[Evert Pot]

I dug deeply into PSR-7, and wrote my final opinion on the current thing
on my blog:

http://evertpot.com/psr-7-issues/

I'm not sure how much this matters for the process of PSR-7. These are
fundamental design disagreements and I don't have strong support from
others in these ideas.

Yes, I brought up mutability and streams again :)

So feel free to ignore it, I just wanted to summarize my feelings and
get it off my chest.

Good luck!

Cheers,
Evert

[Beau Simensen]

The required two week window for review has officially passed. If you have issues or concerns with PSR-7 before it goes up for a vote, you have a very short period of time to comment. Short of any major issues I would expect the vote for PSR-7 to be started shortly after the last round of pull requests are merged.

[Alessandro Pellizzari]

On 2015-03-04 02:50, Evert Pot wrote:

> http://evertpot.com/psr-7-issues/
>
> I'm not sure how much this matters for the process of PSR-7. These
> are
> fundamental design disagreements and I don't have strong support from
> others in these ideas.

However small, you have my strong support. :)

Bye.

[Alexander Makarov]

Hmm... these are quite interesting points.

1. Immutability itself as an API is OK. It looks a bit ugly but that's because we aren't used to it. It could be useful when we'll start writing applications that aren't dying after serving each response.

2. This PSR can't be adopted w/o changing frameworks a lot so the part about "APIs will have to change" isn't really relevant. They have to change anyway. It's actually mentioned in the meta.

3. The issue with sending bytes directly in an efficient manner vs immutability of response is quite worrying.

[Larry Garfield]

On 3/4/15 5:14 AM, Alexander Makarov wrote:
> Hmm... these are quite interesting points.
>
> 1. Immutability itself as an API is OK. It looks a bit ugly but that's
> because we aren't used to it. It could be useful when we'll start
> writing applications that aren't dying after serving each response.
> 2. This PSR can't be adopted w/o changing frameworks a lot so the part
> about "APIs will have to change" isn't really relevant. They have to
> change anyway. It's actually mentioned in the meta

> <https://github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#42-non-goals>.

> 3. The issue with sending bytes directly in an efficient manner vs
> immutability of response is quite worrying.

It is, but I think it's a red herring. As far as sending goes, there's
already code written that will send an arbitrarily large stream

https://github.com/Crell/stacker/blob/master/src/HttpSender.php

Will wrap a modestly-sized string into a stream easily:

https://github.com/Crell/stacker/blob/master/src/StringStream.php

Will handle a callable that generates output on the fly

https://github.com/guzzle/psr7/blob/master/src/PumpStream.php

And although I don't have one off hand one that will grab a file off
disk, that wouldn't be hard to write either. While the "it may not
technically be a PHP stream" issue is still present, and to me very
annoying, and forces a slower output mechanism:

http://www.garfieldtech.com/blog/readfile-memory

As Paul Jones noted the difference is measured in hundredths of a second.

So I think the stream issues are a bit over-blown.

--Larry Garfield

[Alexander Makarov]

Agree. Using php://temp makes the issue at least non-blocker. We can live with it.