Re: New Standardized HTTP Interface

From: 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/

« previous php.internals (#78543) next »