Re: New Standardized HTTP Interface

> On Oct 30, 2014, at 4:15 PM, Andrea Faulds <ajf@ajf.me> wrote: > > >> On 30 Oct 2014, at 20:49, Sherif Ramadan <theanomaly.is@gmail.com> wrote: >> >> 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. 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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >