# New Standardized HTTP Interface - Thread: https://externals.io/message/78477 - Original archive: https://news-web.php.net/php.internals/78477 - Started by Sherif Ramadan on 2014-10-30T18:23:15+00:00 - Messages: 76 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/78477.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #78477 — Sherif Ramadan — 2014-10-30T18:23:15+00:00 URL: https://externals.io/message/78477#78477 Hello Internals, I've been meaning to write up a full-blown RFC for introducing a new standardized HTTP interface for PHP core for some time now. I figure now with PHP 7 on the road map this might be a good time to start this discussion since it involves breaking some backwards compatibility that may have been out of the question in PHP 5. I've started a draft RFC, but please be patient as this is a working in progress, here https://wiki.php.net/rfc/http-interface on the wiki. The point here is to allow users to implement their own HttpRequest and HttpResponse classes that can deal directly with the raw request/response messages in any way the user deems fit. This alleviates cases like "what about when I want to have $_PUT or $_DELETE" and removes the ambiguity of the $_POST, $_GET superglobals to a more conforming way of handling the messages. Since it's an interface, it only dictates the facilitation of PHP's built-in functionality and the user's desired implementation, but no the implementation itself. To remove all confusion, consider the way an HTTP message actually looks. GET /foo?bar=1 HTTP/1.1 Host: foobar.com baz=2 Instead of treating this with current $_GET, $_POST, let's consider for a moment how we might treat it in an HttpRequest object: If the HttpRequest class implements an HttpParameters object that parses and treats the entire HTTP request line as a string of parameters we could accomplish the following... var_dump(HttpRequest::$parameters->bar); // int(1) var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1" Now consider how the body can be treated... echo HttpRequest::$body; // baz=2 echo HttpRequest::$body->baz; // 2 Since the HttpRequest object can lazily parse the body it can also lazily apply custom filters directly to the request variables and parameters... For example, say you wish to treat baz only as an integer? This can be easily accomplished by setting the filters directly in the HttpRequest object and upon access the filter is directly applied to chosen variables. This also alleviates the need to worry about overwriting superglobal variables or having to copy from them. So from an efficiency stand-point this approach works much better. It also allows you to separate clearly between HTTP request parameters and HTTP request body as well as the HTTP request method. Since the request object should be capable of handling callbacks for each method to apply different sets of filters or rules on treating the request body given different request methods this could prove a lot more useful than existing techniques applied directly in PHP with php://input, for example. We don't need to copy the internal stream and we don't need to modify or copy superglobals around to different parts of our code. I'm in the process of writing up a cleaner implementation to introduce in the RFC, but in the mean time I'd like to open up to discussion and see what others think or how they feel we might approach this problem more cleanly. Thanks, Sherif --- ## #78479 — Florian Margaine — 2014-10-30T18:30:08+00:00 URL: https://externals.io/message/78477#78479 · In reply to: #78477 Hi, On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan wrote: > Hello Internals, > > I've been meaning to write up a full-blown RFC for introducing a new > standardized HTTP interface for PHP core for some time now. I figure now > with PHP 7 on the road map this might be a good time to start this > discussion since it involves breaking some backwards compatibility that may > have been out of the question in PHP 5. > > I've started a draft RFC, but please be patient as this is a working in > progress, here https://wiki.php.net/rfc/http-interface on the wiki. > > The point here is to allow users to implement their own HttpRequest and > HttpResponse classes that can deal directly with the raw request/response > messages in any way the user deems fit. This alleviates cases like "what > about when I want to have $_PUT or $_DELETE" and removes the ambiguity of > the $_POST, $_GET superglobals to a more conforming way of handling the > messages. > > Since it's an interface, it only dictates the facilitation of PHP's > built-in functionality and the user's desired implementation, but no the > implementation itself. I find this very... useless. Sure, interfaces are not useless. But I don't think php-src is there to dictate what userland code should look like. It should provide *implementations*, not interfaces. > To remove all confusion, consider the way an HTTP > message actually looks. > > GET /foo?bar=1 HTTP/1.1 > Host: foobar.com > > baz=2 > > Instead of treating this with current $_GET, $_POST, let's consider for a > moment how we might treat it in an HttpRequest object: > > If the HttpRequest class implements an HttpParameters object that parses > and treats the entire HTTP request line as a string of parameters we could > accomplish the following... > > var_dump(HttpRequest::$parameters->bar); // int(1) > var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1" > > Now consider how the body can be treated... > > echo HttpRequest::$body; // baz=2 > echo HttpRequest::$body->baz; // 2 > > Since the HttpRequest object can lazily parse the body it can also lazily > apply custom filters directly to the request variables and parameters... > > For example, say you wish to treat baz only as an integer? This can be > easily accomplished by setting the filters directly in the HttpRequest > object and upon access the filter is directly applied to chosen variables. > This also alleviates the need to worry about overwriting superglobal > variables or having to copy from them. So from an efficiency stand-point > this approach works much better. It also allows you to separate clearly > between HTTP request parameters and HTTP request body as well as the HTTP > request method. Since the request object should be capable of handling > callbacks for each method to apply different sets of filters or rules on > treating the request body given different request methods this could prove > a lot more useful than existing techniques applied directly in PHP with > php://input, for example. > > We don't need to copy the internal stream and we don't need to modify or > copy superglobals around to different parts of our code. > > I'm in the process of writing up a cleaner implementation to introduce in > the RFC, but in the mean time I'd like to open up to discussion and see > what others think or how they feel we might approach this problem more > cleanly. > > Thanks, > Sherif > The other thing I don't like in your RFC is the removal of superglobals. Sure, they're not the best interface out there, but breaking *every single* codebase out there is not the way to go. Especially if we don't want a perl6/python3-like failure to adoption. Regards, -- Florian Margaine --- ## #78482 — Rowan Collins — 2014-10-30T19:14:59+00:00 URL: https://externals.io/message/78477#78482 · In reply to: #78479 Florian Margaine wrote on 30/10/2014 18:30: > Hi, > > On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan > wrote: > > > […] > > I find this very... useless. Sure, interfaces are not useless. But I don't > think php-src is there to dictate what userland code should look like. It > should provide *implementations*, not interfaces. Agreed, I still don't understand the purpose of SplObserver and SplSubject, for instance. To be fair, it's not clear from this early stage whether the RFC is going to define interfaces with a special relationship to core, more like Countable or Iterable. > The other thing I don't like in your RFC is the removal of superglobals. > Sure, they're not the best interface out there, but breaking *every single* > codebase out there is not the way to go. Especially if we don't want a > perl6/python3-like failure to adoption. Yes, this; 1000 times this! I will lay you a bet that if the RFC reaches a vote with the intention to remove superglobals in tact, it will not pass. If that is removed and it provides a useful alternative to superglobals, that allows things not currently possible (e.g. callback request-response patterns, rather than the current one-process-per-thread CGI-style model), then it might be useful. If all you're after is standardised handling in userland, then this is better addressed to PHP-FIG to publish an advisory set of interfaces that major frameworks can transition to from whatever handling they have currently. -- Rowan Collins [IMSoP] --- ## #78484 — Sherif Ramadan — 2014-10-30T19:49:38+00:00 URL: https://externals.io/message/78477#78484 · In reply to: #78479 On Thu, Oct 30, 2014 at 2:30 PM, Florian Margaine wrote: > > > I find this very... useless. Sure, interfaces are not useless. But I don't > think php-src is there to dictate what userland code should look like. It > should provide *implementations*, not interfaces. > Well, let's look at how well providing implementation has worked out for PHP so far. GPC variables are implementation. They pose rigidity to userland code for a number of reasons. For example, if you do send a PUT request to PHP, PHP will not bother populating GPC at all. Instead it leaves the user to define their own handling from the input stream directly. If you do send GET/POST requests to PHP, the variable names can be mangled and $_GET/$_POST are treated differently for encoding as one is run through url_decode and the other is not. $_FILES is also an awkward one as the array is backwardly multidimensional in that $_FILES['userfile'][$meta] are each partitioned rather than having a more intuitive structure wherein one can iterate over the $_FILES['userfile'] array directly. Takeaway: PHP offering up implementation makes userland more rigid. PHP offering up an interface makes userland inherently more appealing and extensible. Take the session interface as one example where we one with interface over implementation. > > > The other thing I don't like in your RFC is the removal of superglobals. > Sure, they're not the best interface out there, but breaking *every single* > codebase out there is not the way to go. Especially if we don't want a > perl6/python3-like failure to adoption. > > I think pitting the Perl 6 and Python 3 scenarios as failure to adoption is like lumping together the Betamax with the Blackberry. Perl 6 failed for a number of reasons, not one of which was an effort to revamp antiquated interfaces. Calling Python 3 a failure to adopt, is a bit ambitious. I don't think people have failed to adopted Python 3. I will tell you what will surely lead to failure, though. When we begin ignoring the problem. Because then we are insisting that the proposed solutions are useless since there is no problem to solve. There is an evident problem in the way PHP handles the incoming Http Request and how it makes it accessible to userland. Whether or not this solution is optimal remains to be seen, but to say that the problem itself is non-existent is pure denial without basis. A failure to act is worse than an act of failure. > Regards, > > -- > Florian Margaine --- ## #78486 — Andrea Faulds — 2014-10-30T20:24:23+00:00 URL: https://externals.io/message/78477#78486 · In reply to: #78484 > > > Well, let's look at how well providing implementation has worked out for > PHP so far. > > GPC variables are implementation. They pose rigidity to userland code for a > number of reasons. For example, if you do send a PUT request to PHP, PHP > will not bother populating GPC at all. Instead it leaves the user to define > their own handling from the input stream directly. If you do send GET/POST > requests to PHP, the variable names can be mangled and $_GET/$_POST are > treated differently for encoding as one is run through url_decode and the > other is not. We could just fix these problems rather than adding an entirely new implementation. -- Andrea Faulds http://ajf.me/ --- ## #78488 — Sherif Ramadan — 2014-10-30T20:33:08+00:00 URL: https://externals.io/message/78477#78488 · In reply to: #78486 > > > […] > wrote: > > […] > for a > > […] > define > > […] > GET/POST > > […] > > We could just fix these problems rather than adding an entirely new > implementation. > Yes, this proposal is intended to do two things. 1) Fix the aforementioned problems. 2) Improve upon the capabilities of PHP's request handling for future use cases through a unified interface. To say that this proposal and fixing the aforementioned problems are two distinct options (as in we can either fix these problems or go with this proposal) is a very reductive form of thinking in which the only outcome favors one party or the other. My proposal is intended to result in a win-win situation where everyone involved can be satisfied, not an ultimatum. If you consider all of the major existing PHP frameworks today there is always some form of HttpRequest class handling these things and almost all of them do it slightly differently. What's worse, is they are all very inefficient implementations that I believe can be done far more efficiently in php-src. A lost of them are also unnecessarily complex. I think all of this can be simplified if the interface is just laid out in a straight-forward manner and then userland implementations will find less and less reason to over-engineer the implementation. > -- > Andrea Faulds > http://ajf.me/ --- ## #78489 — Andrea Faulds — 2014-10-30T20:42:22+00:00 URL: https://externals.io/message/78477#78489 · In reply to: #78488 > > > Yes, this proposal is intended to do two things. 1) Fix the aforementioned problems. By the sounds of things, it doesn’t fix these problems, it just adds a new interface which lacks them. That’s not the same thing. > 2) Improve upon the capabilities of PHP's request handling for future use cases through a unified interface. What unified interface? You’re allowing anyone and everyone to implement their own request handling. > If you consider all of the major existing PHP frameworks today there is always some form of HttpRequest class handling these things and almost all of them do it slightly differently. What's worse, is they are all very inefficient implementations that I believe can be done far more efficiently in php-src. A lost of them are also unnecessarily complex. I think all of this can be simplified if the interface is just laid out in a straight-forward manner and then userland implementations will find less and less reason to over-engineer the implementation. The only reason an implementation of HttpRequest would be inefficient is because it has to work-around problems with $_GET and $_POST. Problems we could simply fix. -- Andrea Faulds http://ajf.me/ --- ## #78490 — Sherif Ramadan — 2014-10-30T20:49:58+00:00 URL: https://externals.io/message/78477#78490 · In reply to: #78489 > > > […] > wrote: > > […] > aforementioned problems. > > By the sounds of things, it doesn’t fix these problems, it just adds a new > interface which lacks them. That’s not the same thing. > > No, the interface makes it possible to implement your own behavior, but it does not prevent PHP from implementing default behavior. In that PHP would implement its own HttpRequest class, for example, which the user can then extend to override default behavior or modify it as they see fit for their particular use case. This is much like the Session interface, which makes it possible to change session storage mechanisms in userland, but still have a confirming method of session handling in PHP. > > […] > use cases through a unified interface. > > What unified interface? You’re allowing anyone and everyone to implement > their own request handling. > Yes, by allowing this you make it extensible. However, having the interface is what makes it possible to unify the efforts of dealing with the HTTP messages both in userland and in PHP internals. > > > […] > always some form of HttpRequest class handling these things and almost all > of them do it slightly differently. What's worse, is they are all very > inefficient implementations that I believe can be done far more efficiently > in php-src. A lost of them are also unnecessarily complex. I think all of > this can be simplified if the interface is just laid out in a > straight-forward manner and then userland implementations will find less > and less reason to over-engineer the implementation. > > The only reason an implementation of HttpRequest would be inefficient is > because it has to work-around problems with $_GET and $_POST. Problems we > could simply fix. > So the fix to something like PUT/DELETE requests is to add yet another superglobal. However, this is still a very rigid fix that requires continuous maintenance and fulfilling feature requests on the part of internals. Think of implementing a new session handler for every session storage mechanism in PHP. This is a lot of unneeded effort when we can just expose the session interface to userland and make it extensible by nature. The alternative is far more useful and less closed up (preventing future problems to fix). Let's not also ignore the fact that such features have been forsaken by PHP internals for years. I have bug reports dating back to 2010 that have asked for such features that have long been unanswered. So the current desire to fix anything along these lines appears to be minimal, if not non-existent, right now. > > -- > Andrea Faulds > http://ajf.me/ --- ## #78492 — Andrea Faulds — 2014-10-30T21:15:41+00:00 URL: https://externals.io/message/78477#78492 · In reply to: #78490 > > > No, the interface makes it possible to implement your own behavior, but it does not prevent PHP from implementing default behavior. In that PHP would implement its own HttpRequest class, for example, which the user can then extend to override default behavior or modify it as they see fit for their particular use case. This is much like the Session interface, which makes it possible to change session storage mechanisms in userland, but still have a confirming method of session handling in PHP. You know, before I keep up this discussion, it’d be nice if you clarified what, exactly, you are proposing. The RFC contains no detail at all. I really haven’t the faintest. Also, removing $_GET and $_POST is a *massive* backwards-compatibility break. I would vote against this proposal and I hope everyone else will join me in doing so, for that reason alone. Please, don’t completely break every single PHP site I’ve ever written. :( > So the fix to something like PUT/DELETE requests is to add yet another super global. No, not really. $_PUT and $_DELETE don’t really make sense, why are you sending form data to PUT or DELETE? Populating $_POST also makes sense, it’s not a POST request. The answer is just to add a function to do multipart parsing, to expose PHP’s current parser, which satisfies the obscure use case of needing form data parsing for PUT and DELETE. I don’t think this would be too hard to do. -- Andrea Faulds http://ajf.me/ --- ## #78493 — Will Fitch — 2014-10-30T21:26:52+00:00 URL: https://externals.io/message/78477#78493 · In reply to: #78492 > > > > > […] > > You know, before I keep up this discussion, it’d be nice if you clarified what, exactly, you are proposing. The RFC contains no detail at all. I really haven’t the faintest. > > Also, removing $_GET and $_POST is a *massive* backwards-compatibility break. I would vote against this proposal and I hope everyone else will join me in doing so, for that reason alone. > > Please, don’t completely break every single PHP site I’ve ever written. :( > > > […] > > No, not really. $_PUT and $_DELETE don’t really make sense, why are you sending form data to PUT or DELETE? Populating $_POST also makes sense, it’s not a POST request. The answer is just to add a function to do multipart parsing, to expose PHP’s current parser, which satisfies the obscure use case of needing form data parsing for PUT and DELETE. I don’t think this would be too hard to do. It's not hard. Again, pecl/http v2 proposal will give core everything it needs. I honestly don't know why this is being discussed any further when theirs a solution that gives functionality requested here and contains zero BC breaks. > -- > Andrea Faulds > http://ajf.me/ --- ## #78495 — Larry Garfield — 2014-10-30T22:15:23+00:00 URL: https://externals.io/message/78477#78495 · In reply to: #78477 > Hello Internals, > > I've been meaning to write up a full-blown RFC for introducing a new > standardized HTTP interface for PHP core for some time now. I figure now > with PHP 7 on the road map this might be a good time to start this > discussion since it involves breaking some backwards compatibility that may > have been out of the question in PHP 5. *snip* > I'm in the process of writing up a cleaner implementation to introduce in > the RFC, but in the mean time I'd like to open up to discussion and see > what others think or how they feel we might approach this problem more > cleanly. > > Thanks, > Sherif As you note, there's an enormous amount of existing and active discussion around PSR-7 on the FIG mailing list, and I would urge anyone pursuing such an effort for core to read through that discussion in detail. There are a lot of tricky bits that we have been hashing through that you don't want to hash through again, especially around supported use cases. In practice, honestly, I think userspace can experiment and innovate here better than internals can, at least for a while. The main place where core could help would be streams. One of the things we're still struggling with is supporting message bodies (request or response) that can be strings OR a stream, such as a file off disk that we don't want in memory all at once, OR a callable that generates output on the fly (say, reading records out of a DB and generating a CSV file). Part of the problem is that the native streams API, while powerful, is horribly annoying to work with. Michael Dowling has documented many of the issues with it from a request/response perspective here: http://mtdowling.com/blog/2014/07/03/a-case-for-higher-level-php-streams/ Honestly, I think one of the best things internals could do to help really robust request/response support for PHP 7 isn't writing a new interface, but improving the streams API in order to simplify the many use cases we've identified (and render the whole "detach" stuff we're looking at now unnecessary). --Larry Garfield --- ## #78499 — Sherif Ramadan — 2014-10-31T02:54:05+00:00 URL: https://externals.io/message/78477#78499 · In reply to: #78495 So far there seems to be a lot of concern around BC, and particularly removing or getting rid of GPC superglobals. So I completely understand the concerns and hope to address them as clearly as possible. First, for the sake of BC I think removing the superglobals from the language should not be done here. Instead, for performance reasons, I'm going to propose that the superglobals are not populated at the request level. This means that the implementation is free to populate them at will since they will still exist, but will be initialized to empty arrays by the language. Second, it's a valid concern that's there's no actual proposed interface. So let me be begin by proposing a rough draft for one. So let's consider the following interface layout and some sample implementations as a start... https://gist.github.com/srgoogleguy/f729053e3e88b2d2b3ec Then let's consider the kind of flexibility this would allow userland in terms of filtering, validating, and modifying the request data under various conditions. Obviously, PHP has to provide some form of default implementation so some base class HttpRequest can be implemented in PHP and this can be easily extended by userland. Also, take into consideration the kind of performance gains you might get out of this by doing things like lazy-loading or lazy parsing or lazy-filtering of request data. Filters also need not be applied at the global level. PHP's default implementation would simply use the input stream to populate GPC as normal (as it currently does), but I believe introducing the base class will encourage others to make better use of request/response handling in their own code. --- ## #78503 — Andrea Faulds — 2014-10-31T09:25:51+00:00 URL: https://externals.io/message/78477#78503 · In reply to: #78499 > > > So far there seems to be a lot of concern around BC, and particularly > removing or getting rid of GPC superglobals. So I completely understand the > concerns and hope to address them as clearly as possible. > > First, for the sake of BC I think removing the superglobals from the > language should not be done here. Instead, for performance reasons, I'm > going to propose that the superglobals are not populated at the request > level. This means that the implementation is free to populate them at will > since they will still exist, but will be initialized to empty arrays by the > language. This is no less of a backwards-compatibility headache. This still breaks every PHP app I have ever written. > > Second, it's a valid concern that's there's no actual proposed interface. > So let me be begin by proposing a rough draft for one. > > So let's consider the following interface layout and some sample > implementations as a start... > > https://gist.github.com/srgoogleguy/f729053e3e88b2d2b3ec > > Then let's consider the kind of flexibility this would allow userland in > terms of filtering, validating, and modifying the request data under > various conditions. Obviously, PHP has to provide some form of default > implementation so some base class HttpRequest can be implemented in PHP and > this can be easily extended by userland. > > Also, take into consideration the kind of performance gains you might get > out of this by doing things like lazy-loading or lazy parsing or > lazy-filtering of request data. Filters also need not be applied at the > global level. PHP's default implementation would simply use the input > stream to populate GPC as normal (as it currently does), but I believe > introducing the base class will encourage others to make better use of > request/response handling in their own code. No no, I'm not concerned about the contents of the interface. I'm wondering what, exactly, this "interface" does? I don't see how a mere interface would replace the superglobals, unless you want a superglobal request object that anyone can swap out, which sounds like a bad idea. -- Andrea Faulds http://ajf.me/ --- ## #78508 — Sherif Ramadan — 2014-10-31T14:30:52+00:00 URL: https://externals.io/message/78477#78508 · In reply to: #78503 > > > This is no less of a backwards-compatibility headache. This still breaks > every PHP app I have ever written. > > To be perfectly clear, the default behavior would remain the same, so no PHP app you have ever written would break. The difference is, you would now be able to override any part of the default behavior by extending the HttpRequest class in your own code. > > > No no, I'm not concerned about the contents of the interface. I'm > wondering what, exactly, this "interface" does? I don't see how a mere > interface would replace the superglobals, unless you want a superglobal > request object that anyone can swap out, which sounds like a bad idea. > > The interfaces do exactly what you see here. They specified which methods the HttpRequest and HttpResponse objects must implement. If you bothered to invest nearly as much time in reading the updates to the RFC as you did to making blanket statements and objections, you might actually find less reason to respond with objections so abruptly. The HttpRequest and HttpResponse classes are intended to provide a central place for message handling behaviors and their properties can be used to describe these behaviors. So, if you wanted to support a $_PUT superglobal, rather than adding one to the language, you can simply add the behavior to do the processing of PUT requests in your HttpRequest class, by extending HttpRequest and defining how PUT variables are handled there. > -- > Andrea Faulds > http://ajf.me/ --- ## #78510 — Rowan Collins — 2014-10-31T15:56:04+00:00 URL: https://externals.io/message/78477#78510 · In reply to: #78508 Sherif Ramadan wrote on 31/10/2014 14:30: > > > > […] > To be perfectly clear, the default behavior would remain the same, so no > PHP app you have ever written would break. The difference is, you would now > be able to override any part of the default behavior by extending the > HttpRequest class in your own code. > > > > […] > The interfaces do exactly what you see here. They specified which methods > the HttpRequest and HttpResponse objects must implement. > > If you bothered to invest nearly as much time in reading the updates to the > RFC as you did to making blanket statements and objections, you might > actually find less reason to respond with objections so abruptly. The > HttpRequest and HttpResponse classes are intended to provide a central > place for message handling behaviors and their properties can be used to > describe these behaviors. > > So, if you wanted to support a $_PUT superglobal, rather than adding one to > the language, you can simply add the behavior to do the processing of PUT > requests in your HttpRequest class, by extending HttpRequest and defining > how PUT variables are handled there. I think the piece that's missing is how exactly these interfaces would interact with core, or rather with the SAPIs which handle the actual transfer of HTTP requests and responses. Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive", what do I then do with this class in order for it to perform any actions? Presumably there will need to be some mechanism where I can register this so that it is passed the actual data from the PHP SAPI? In order to actually replace the default behaviour, this would need to be an ini setting, since no PHP code can run before the default superglobal behaviour occurs. Alternatively, it could be repeatable, by having some global function like populate_http_message_object( new AwesomeHTTPReceive ); Similarly, there would need to be some mechanism for tying up the response object to the HTTP response to be issued by the SAPI, with some way for existing functions such as `header()` to interact with it appropriately. -- Rowan Collins [IMSoP] --- ## #78516 — Andrea Faulds — 2014-10-31T16:04:42+00:00 URL: https://externals.io/message/78477#78516 · In reply to: #78508 > > > To be perfectly clear, the default behavior would remain the same, so no PHP app you have ever written would break. The difference is, you would now be able to override any part of the default behavior by extending the HttpRequest class in your own code. So there’s still a default implementation, then? So, if you want to parse in userland, how does that work? The default implementation fills in the variables and then your implementation parses it again, wasting CPU time and making the request take longer? Or does the default implementation do nothing at all unless asked to, breaking existing apps unless they’re modified to request parsing? Or is it INI-determined?? > The interfaces do exactly what you see here. They specified which methods the HttpRequest and HttpResponse objects must implement. OK. So they’re just interfaces, then? In which case, why not leave the PHP-FIG to finish its HTTP Message proposal instead? > If you bothered to invest nearly as much time in reading the updates to the RFC as you did to making blanket statements and objections, you might actually find less reason to respond with objections so abruptly. The HttpRequest and HttpResponse classes are intended to provide a central place for message handling behaviors and their properties can be used to describe these behaviors. > > So, if you wanted to support a $_PUT superglobal, rather than adding one to the language, you can simply add the behavior to do the processing of PUT requests in your HttpRequest class, by extending HttpRequest and defining how PUT variables are handled there. So, all you’re proposing is a set of interfaces, to compete with the work the PHP-FIG is doing. I don’t see how this is useful. How, exactly, does adding interfaces solve the problems with superglobals? Because you’re creating a common standard for alternative request implementations? But, we already have such a WIP standard in userland from the PSR people. I really don’t get this RFC. If this was to add implementations of the PSR Request/Response stuff, that might be useful. But merely adding new interfaces… I don’t get it. Why duplicate effort? How does this fix superglobals? -- Andrea Faulds http://ajf.me/ --- ## #78511 — Sherif Ramadan — 2014-10-31T16:07:26+00:00 URL: https://externals.io/message/78477#78511 · In reply to: #78510 On Fri, Oct 31, 2014 at 11:56 AM, Rowan Collins wrote: > > I think the piece that's missing is how exactly these interfaces would > interact with core, or rather with the SAPIs which handle the actual > transfer of HTTP requests and responses. > PHP would have an HttpRequest class, as noted in the updated RFC, which implements the HttpMessageReceive interface. The HttpRequest class's default behavior would be to just populate the superglobals (i.e. having the same net-effect as the current behavior). If a user wanted to override that default behavior they would just extend HttpRequest and implement the functions/methods they wanted to override. --- ## #78515 — Andrea Faulds — 2014-10-31T16:19:21+00:00 URL: https://externals.io/message/78477#78515 · In reply to: #78477 > > > I've started a draft RFC, but please be patient as this is a working in > progress, here https://wiki.php.net/rfc/http-interface on the wiki. > > The point here is to allow users to implement their own HttpRequest and > HttpResponse classes that can deal directly with the raw request/response > messages in any way the user deems fit. This alleviates cases like "what > about when I want to have $_PUT or $_DELETE" and removes the ambiguity of > the $_POST, $_GET superglobals to a more conforming way of handling the > messages. OK, I’ve gone and re-read the RFC and I finally understand this proposal, sorry for my previous misunderstanding. You’re proposing a mechanism to plug in your own parser for the HTTP message headers and body, right? I’m not sure I really see what it solves, though? Why should we allow users to implement their own slow parsers in userland? Why can’t we just have a single built-in parser like we’ve had the last two decades? I don’t see the point. -- Andrea Faulds http://ajf.me/ --- ## #78514 — Paul Dragoonis — 2014-10-31T16:44:32+00:00 URL: https://externals.io/message/78477#78514 · In reply to: #78477 > > Hello Internals, > > I've been meaning to write up a full-blown RFC for introducing a new > standardized HTTP interface for PHP core for some time now. I figure now > with PHP 7 on the road map this might be a good time to start this > discussion since it involves breaking some backwards compatibility that may > have been out of the question in PHP 5. > > I've started a draft RFC, but please be patient as this is a working in > progress, here https://wiki.php.net/rfc/http-interface on the wiki. > > The point here is to allow users to implement their own HttpRequest and > HttpResponse classes that can deal directly with the raw request/response > messages in any way the user deems fit. This alleviates cases like "what > about when I want to have $_PUT or $_DELETE" and removes the ambiguity of > the $_POST, $_GET superglobals to a more conforming way of handling the > messages. > > Since it's an interface, it only dictates the facilitation of PHP's > built-in functionality and the user's desired implementation, but no the > implementation itself. To remove all confusion, consider the way an HTTP > message actually looks. > > GET /foo?bar=1 HTTP/1.1 > Host: foobar.com > > baz=2 > > Instead of treating this with current $_GET, $_POST, let's consider for a > moment how we might treat it in an HttpRequest object: > > If the HttpRequest class implements an HttpParameters object that parses > and treats the entire HTTP request line as a string of parameters we could > accomplish the following... > > var_dump(HttpRequest::$parameters->bar); // int(1) > var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1" > > Now consider how the body can be treated... > > echo HttpRequest::$body; // baz=2 > echo HttpRequest::$body->baz; // 2 > > Since the HttpRequest object can lazily parse the body it can also lazily > apply custom filters directly to the request variables and parameters... > > For example, say you wish to treat baz only as an integer? This can be > easily accomplished by setting the filters directly in the HttpRequest > object and upon access the filter is directly applied to chosen variables. > This also alleviates the need to worry about overwriting superglobal > variables or having to copy from them. So from an efficiency stand-point > this approach works much better. It also allows you to separate clearly > between HTTP request parameters and HTTP request body as well as the HTTP > request method. Since the request object should be capable of handling > callbacks for each method to apply different sets of filters or rules on > treating the request body given different request methods this could prove > a lot more useful than existing techniques applied directly in PHP with > php://input, for example. > > We don't need to copy the internal stream and we don't need to modify or > copy superglobals around to different parts of our code. > > I'm in the process of writing up a cleaner implementation to introduce in > the RFC, but in the mean time I'd like to open up to discussion and see > what others think or how they feel we might approach this problem more > cleanly. > > Thanks, > Sherif This is clearly a responsibility of PHPFIG for interface recommendations and not the responsibility of the core language. --- ## #78519 — Rowan Collins — 2014-10-31T17:09:36+00:00 URL: https://externals.io/message/78477#78519 · In reply to: #78511 Sherif Ramadan wrote on 31/10/2014 16:07: > > > On Fri, Oct 31, 2014 at 11:56 AM, Rowan Collins > > wrote: > > > I think the piece that's missing is how exactly these interfaces > would interact with core, or rather with the SAPIs which handle > the actual transfer of HTTP requests and responses. > > > PHP would have an HttpRequest class, as noted in the updated RFC, > which implements the HttpMessageReceive interface. The HttpRequest > class's default behavior would be to just populate the superglobals > (i.e. having the same net-effect as the current behavior). > > If a user wanted to override that default behavior they would just > extend HttpRequest and implement the functions/methods they wanted to > override. Let me repeat my question: Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive", what do I then do with this class in order for it to perform any actions? How does PHP know that my class is the one it should populate, or when that population should happen? --- ## #78521 — Sherif Ramadan — 2014-10-31T17:17:20+00:00 URL: https://externals.io/message/78477#78521 · In reply to: #78515 > > > > I’m not sure I really see what it solves, though? Why should we allow > users to implement their own slow parsers in userland? Why can’t we just > have a single built-in parser like we’ve had the last two decades? I don’t > see the point. > > For one, it would solve the problem addressed by the bug report ( http://php.net/55815) listed in the RFC, where users are asking for additional features to parse and handle different kinds of requests like PUT, which PHP currently doesn't do. Additionally, it solves problems such as filtering input from the request with a more abstract interface that doesn't rely on modifying or copying globals. The implementation can be devised to do filtering at the request level or even lazy-loaded so that filters are only applied when the data is requested. In addition, you could utilize this approach to apply different kinds of custom filters based on the request type using the onReceive hook, for example. Further more it can be used to ensure that the request data is immutable so that there is no wonder if the superglobals have been modified/tainted. This is something many frameworks try to abstract themselves in fear that someone might accidentally modify the superglobal variables (as this is very easy to do in userland). --- ## #78522 — Sherif Ramadan — 2014-10-31T17:24:27+00:00 URL: https://externals.io/message/78477#78522 · In reply to: #78516 > > > > So there’s still a default implementation, then? So, if you want to parse > in userland, how does that work? The default implementation fills in the > variables and then your implementation parses it again, wasting CPU time > and making the request take longer? Or does the default implementation do > nothing at all unless asked to, breaking existing apps unless they’re > modified to request parsing? Or is it INI-determined?? > No, by overriding the parseBody or parseParameters methods, for example, you can prevent the default behavior from happening. (i.e. it is not doing the same thing twice). Simply by extending the HttpRequest class, we can call on the child class instead. Any methods not implemented in the extending class would be forwarded to the parent class as per normal PHP inheritance rules. > > > OK. So they’re just interfaces, then? In which case, why not leave the > PHP-FIG to finish its HTTP Message proposal instead? > > > *snip* > So, all you’re proposing is a set of interfaces, to compete with the work > the PHP-FIG is doing. > > I don’t see how this is useful. How, exactly, does adding interfaces solve > the problems with superglobals? Because you’re creating a common standard > for alternative request implementations? But, we already have such a WIP > standard in userland from the PSR people. > > I really don’t get this RFC. If this was to add implementations of the PSR > Request/Response stuff, that might be useful. But merely adding new > interfaces… I don’t get it. Why duplicate effort? How does this fix > superglobals? > > Competing ideas are good and the very reason that drives innovation. This proposal is for both the interface and the implementing class, which can be extended to create custom behavior in handling the HTTP request/response. I have no idea why you think PHP-FIG or PSR is involved in this conversation. This is a PHP internals matter and should be considered for PHP internals purposes. The benefits and cons of this proposal are pretty clear, I think. You get the ability to handle different kinds of requests as you see fit or you leave the default behavior intact and everyone wins. The only thing you don't get if you do this in userland instead, is you have to do the parsing of the message twice, which this RFC attempts to circumvent, but offering a way to overrride the parser before parsing takes place (if you choose to implement it). --- ## #78523 — Sherif Ramadan — 2014-10-31T17:27:40+00:00 URL: https://externals.io/message/78477#78523 · In reply to: #78519 On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins wrote: > > Let me repeat my question: > > Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive", > what do I then do with this class in order for it to perform any actions? > > How does PHP know that my class is the one it should populate, or when > that population should happen? > It wouldn't. You would need to extend the base class, since it already implements the necessary interface. PHP would simply call on the last subtype of HttpRequest during the request init phase. Of course, this is an implementation detail as of now. There could certainly be other/better ways to accomplish this. I just want to keep it as simple as possible for now without introducing more configuration nightmares that people often complain about. I really don't like the idea of adding yet another INI directive to control this behavior (making it harder to port). What do you propose? --- ## #78524 — Florian Margaine — 2014-10-31T17:32:18+00:00 URL: https://externals.io/message/78477#78524 · In reply to: #78523 Hi, Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit : > > On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins > wrote: > > > […] actions? > > […] > > > It wouldn't. You would need to extend the base class, since it already > implements the necessary interface. PHP would simply call on the last > subtype of HttpRequest during the request init phase. What if there is multiple subtypes? class A extends HttpRequest {} class B extends HttpRequest {} What happens there? > Of course, this is an > implementation detail as of now. There could certainly be other/better ways > to accomplish this. I just want to keep it as simple as possible for now > without introducing more configuration nightmares that people often > complain about. I really don't like the idea of adding yet another INI > directive to control this behavior (making it harder to port). > > What do you propose? Regards, Florian Margaine --- ## #78525 — Sherif Ramadan — 2014-10-31T17:38:15+00:00 URL: https://externals.io/message/78477#78525 · In reply to: #78524 On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine wrote: > Hi, > > Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit > : > > […] > actions? > > […] > > What if there is multiple subtypes? > > class A extends HttpRequest {} > class B extends HttpRequest {} > > What happens there? > As of now, all the subtypes would be called, i.e. if A has a receiveMessage method, it would be handed the message, and if B has a receiveMessage method it too would be handed the message. It's up to those methods to call on subsequent parsing methods to do something with the message, obviously any methods they don't implement are forwarded to the parent. This clearly has some conflicts, like if default parsing is left we overwrite superglobal variables. However, it also has benefits, in that we can have multiple implementations for handling the request in the same code base and it is left up to the user to decide which one to use. So, again, this is still a draft and I'm open to suggestions about how to handle/deal with such problems. > > […] > ways > > […] > > Regards, > Florian Margaine --- Next page: https://externals.io/message/78477.md?page=2