Re: New Standardized HTTP Interface
| From: | Andrea Faulds | Date: | Sat, 01 Nov 2014 12:40:55 +0000 |
| Subject: | Re: New Standardized HTTP Interface | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78543@lists.php.net to get a copy of this message | ||
> On 31 Oct 2014, at 18:37, Larry Garfield <larry@garfieldtech.com> wrote:
>
> I think the root problem is that you're solving an issue that doesn't exist.
>
> You're talking about providing alternate ways to parse the raw HTTP stream into
> user-accessible variables, ie, by pushing them into an object of a known interface rather than/in
> addition to the superglobals.
>
> In my 15 years of writing PHP I have never wanted to change the way the raw HTTP is parsed. I
> have, however, frequently wanted to have the data accessible in a more logical, semantic, and
> HTTP-correct way. ($_GET is not about HTTP GET, it's about URI query parameters. $_POST
> isn't about HTTP POST, it's about application/x-www-form-encoded. Etc.) And I've
> wanted that information available in a non-global, OOP-injectable way. But I've never once had
> any desire to change the way an application/x-www-form-encoded is parsed.
>
> Implementation problems aside, your proposal is not solving an extant problem.
>
> If we want to improve PHP's HTTP handling, then having an object that exposes the HTTP
> request in a more logical fashion would be far more useful, and/or providing that data in a more
> logical way so that someone in user-space can provide that data in a logical fashion (eg, via a
> PSR-7-implementing object.) I already stated in an earlier email what I felt would be most
> beneficial for internals to do toward that goal (specifically, clean up the streams API so that we
> can use it directly from an OOP world rather than a 1980s C world.)
>
> IF internals wanted to add implementation, not just improving streams, something like the
> following would be much more useful:
>
> $request = http_get_request(PHP_STDIN); // or something
>
> Where $request is an object that implements the PSR-7 RequestInterface (or at least the
> read-only parts of it), or something similar. Then implementers can compose that object however
> they want.
>
> Although at least for the near term I think it's better to not do that and just do the
> lower-level plumbing to make FIG's work with PSR-7 easier.
This sums up my thoughts on this very well. Nobody needs to change how we parse the data. We just
need better access to the results of the parsing.
--
Andrea Faulds
http://ajf.me/