[PHP-DEV] New Standardized HTTP Interface

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

Re: [PHP-DEV] New Standardized HTTP Interface

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 >

Re: [PHP-DEV] New Standardized HTTP Interface

Florian Margaine wrote on 30/10/2014 18:30: Hi, On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan wrote: 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... usel

Re: [PHP-DEV] New Standardized HTTP Interface

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

Re: [PHP-DEV] New Standardized HTTP Interface

> On 30 Oct 2014, at 19:49, Sherif Ramadan wrote: > > 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

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Oct 30, 2014 at 4:24 PM, Andrea Faulds wrote: > > > On 30 Oct 2014, at 19:49, Sherif Ramadan > wrote: > > > > 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 > >

Re: [PHP-DEV] New Standardized HTTP Interface

> On 30 Oct 2014, at 20:33, Sherif Ramadan wrote: > > 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

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Oct 30, 2014 at 4:42 PM, Andrea Faulds wrote: > > > On 30 Oct 2014, at 20:33, Sherif Ramadan > wrote: > > > > 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

Re: [PHP-DEV] New Standardized HTTP Interface

> On 30 Oct 2014, at 20:49, Sherif Ramadan 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

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 30, 2014, at 4:15 PM, Andrea Faulds wrote: > > >> On 30 Oct 2014, at 20:49, Sherif Ramadan 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 Htt

Re: [PHP-DEV] New Standardized HTTP Interface

On 10/30/14, 1: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 involv

Re: [PHP-DEV] New Standardized HTTP Interface

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 do

Re: [PHP-DEV] New Standardized HTTP Interface

> On 31 Oct 2014, at 02:54, Sherif Ramadan wrote: > > 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 t

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds wrote: > > > 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 dif

Re: [PHP-DEV] New Standardized HTTP Interface

Sherif Ramadan wrote on 31/10/2014 14:30: On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds wrote: 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 h

Re: [PHP-DEV] New Standardized HTTP Interface

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 t

Re: [PHP-DEV] New Standardized HTTP Interface

On 30 Oct 2014 19:03, "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 s

Re: [PHP-DEV] New Standardized HTTP Interface

> On 30 Oct 2014, at 18:23, Sherif Ramadan wrote: > > 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

Re: [PHP-DEV] New Standardized HTTP Interface

> On 31 Oct 2014, at 14:30, Sherif Ramadan wrote: > > 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 cl

Re: [PHP-DEV] New Standardized HTTP Interface

Sherif Ramadan wrote on 31/10/2014 16:07: On Fri, Oct 31, 2014 at 11:56 AM, Rowan Collins mailto:rowan.coll...@gmail.com>> 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

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 12:19 PM, Andrea Faulds wrote: > > > > 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 po

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 12:04 PM, Andrea Faulds wrote: > > > > 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 maki

Re: [PHP-DEV] New Standardized HTTP Interface

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 pop

Re: [PHP-DEV] New Standardized HTTP Interface

Hi, Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit : > > 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

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine wrote: > Hi, > > Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit > : > > > > On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins > > wrote: > > > > > > > > Let me repeat my question: > > > > > > Say I write a class "AwesomeHTTPReceive implements Http

Re: [PHP-DEV] New Standardized HTTP Interface

On 10/31/14, 12:38 PM, Sherif Ramadan wrote: On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine wrote: Hi, Le 31 oct. 2014 18:28, "Sherif Ramadan" a écrit : On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins wrote: Let me repeat my question: Say I write a class "AwesomeHTTPReceive implemen

Re: [PHP-DEV] New Standardized HTTP Interface

So for the purposes of this discussion and in an effort to remain on-topic and productive, let's keep all of the FIG/PSR and other third party efforts out of the discussion unless it is intended to improve/help this particular RFC. Please keep in mind that this is a PHP internals discussion and not

Re: [PHP-DEV] New Standardized HTTP Interface

On 10/31/14, 1:52 PM, Sherif Ramadan wrote: So for the purposes of this discussion and in an effort to remain on-topic and productive, let's keep all of the FIG/PSR and other third party efforts out of the discussion unless it is intended to improve/help this particular RFC. Please keep in mind t

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 3:00 PM, Larry Garfield wrote: > On 10/31/14, 1:52 PM, Sherif Ramadan wrote: > >> >> > This RFC has two primary goals in mind: >> >> 1) Expose the parsing/handling of the HTTP request to userland in a >> consistent way >> > > It already is. It's the access TO that parsed

Re: [PHP-DEV] New Standardized HTTP Interface

Sherif Ramadan wrote on 31/10/2014 18:52: This RFC is about core PHP and I really don't care how many competing ideas exist out there that are closely or mildly related to this RFC. The decision about *whether this is needed in core* is not something you can ignore by saying "this is about cor

Re: [PHP-DEV] New Standardized HTTP Interface

Sherif Ramadan wrote on 31/10/2014 17:27: On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins mailto:rowan.coll...@gmail.com>> 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

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins wrote: > Sherif Ramadan wrote on 31/10/2014 18:52: > >> This RFC is about core PHP and I really don't care how >> many competing ideas exist out there that are closely or mildly related to >> this RFC. >> > > The decision about *whether this is neede

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:05 PM, Sherif Ramadan wrote: > > On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins > wrote: > >> Sherif Ramadan wrote on 31/10/2014 18:52: >> >>> This RFC is about core PHP and I really don't care how >>> many competing ideas exist out there that are closely or mildly rel

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote: > > > > While not too specific to Rowan, reiterating the pecl/http approach is > indirectly what your asking for? I have mentioned this numerous times, but > you haven’t responded with a reason not to take this approach - which is an > RFC that w

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan wrote: > > > > On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch > wrote: > > > > While not too specific to Rowan, reiterating the pecl/http approach is > indirectly what your asking for? I have mentioned this numerous time

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch wrote: > > On Oct 31, 2014, at 4:21 PM, Sherif Ramadan > wrote: > > > > On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote: > >> >> >> >> While not too specific to Rowan, reiterating the pecl/http approach is >> indirectly what your asking for? I have

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:51 PM, Sherif Ramadan wrote: > > On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch wrote: > >> >> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan >> wrote: >> >> >> >> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote: >> >>> >>> >>> >>> While not too specific to Rowan,

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Oct 31, 2014 at 5:01 PM, Will Fitch wrote: > > > > I’m actually not suggesting an alternative - I’m suggesting this RFC isn’t > an option. > > Great, your suggestion has been noted. Thanks for your contribution to this discussion! :)

Re: [PHP-DEV] New Standardized HTTP Interface

On 10/31/14, 4:19 PM, Sherif Ramadan wrote: On Fri, Oct 31, 2014 at 5:01 PM, Will Fitch wrote: I’m actually not suggesting an alternative - I’m suggesting this RFC isn’t an option. Great, your suggestion has been noted. Thanks for your contribution to this discussion! :) Let's try a

Re: [PHP-DEV] New Standardized HTTP Interface

> On 31 Oct 2014, at 18:37, Larry Garfield 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 > i

Re: [PHP-DEV] New Standardized HTTP Interface

On Sat, Nov 1, 2014 at 1:40 PM, Andrea Faulds wrote: > > On 31 Oct 2014, at 18:37, Larry Garfield wrote: > > 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 so

Re: [PHP-DEV] New Standardized HTTP Interface

On 1 November 2014 13:15:45 GMT, Damien Tournoud wrote: >On Sat, Nov 1, 2014 at 1:40 PM, Andrea Faulds wrote: >> > On 31 Oct 2014, at 18:37, Larry Garfield >wrote: >> > IF internals wanted to add implementation, not just improving >streams, something like the following would be much more useful:

Re: [PHP-DEV] New Standardized HTTP Interface

Hi! > 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. I think removing $_* is a no go and even discussing it is kind of pointless unless somebody wants

Re: [PHP-DEV] New Standardized HTTP Interface

2014-10-30 19:23 GMT+01:00 Sherif Ramadan : > 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

Re: [PHP-DEV] New Standardized HTTP Interface

I'm not keen on the idea of adding more superglobals to PHP, although I certainly understand the grave concern of breaking people's code and as such I've chosen not to pursue the idea of removing superglobals. I will, however, revisit the idea of exposing the underlying SAPI callbacks, for handlin

Re: [PHP-DEV] New Standardized HTTP Interface

Me as a user and developer PHP RESTful, enough auto filling the global variable. Make an abstract variable names (_BODY or _FORM), and filled with the value in all the HTTP methods. Perhaps it makes sense to do lazy loading of data in these variables, it is simply done through an ArrayAccess inter

Re: [PHP-DEV] New Standardized HTTP Interface

> On 5 Nov 2014, at 22:29, Sherif Ramadan wrote: > > From all the people I've spoken with that have a problem with handling PUT > requests in PHP, it seems that they'd rather have PHP populate > $_FILES/$_POST automatically in this case. Which would be relatively easy > to do by modifying the de

Re: [PHP-DEV] New Standardized HTTP Interface

On Wed, Nov 5, 2014 at 7:31 PM, Andrea Faulds wrote: > > > On 5 Nov 2014, at 22:29, Sherif Ramadan wrote: > > > > From all the people I've spoken with that have a problem with handling > PUT > > requests in PHP, it seems that they'd rather have PHP populate > > $_FILES/$_POST automatically in th

Re: [PHP-DEV] New Standardized HTTP Interface

> On 6 Nov 2014, at 01:29, Sherif Ramadan wrote: > > So you're actually describing two semi-different problems here. One is that > PHP doesn't actually inform you of the HTTP request VERB strictly through the > naming of the super global variables $_POST and $_GET. However, $_POST being > pop

Re: [PHP-DEV] New Standardized HTTP Interface

On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote: > > > On 6 Nov 2014, at 01:29, Sherif Ramadan wrote: > > > > So you're actually describing two semi-different problems here. One is > that PHP doesn't actually inform you of the HTTP request VERB strictly > through the naming of the super glob

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 5, 2014, at 9:23 PM, Sherif Ramadan wrote: > > On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote: > >> >>> On 6 Nov 2014, at 01:29, Sherif Ramadan wrote: >>> >>> So you're actually describing two semi-different problems here. One is >> that PHP doesn't actually inform you of the

Re: [PHP-DEV] New Standardized HTTP Interface

On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote: > > > > Easy - you have no idea what the input type is from PUT without checking > the incoming type. With POST, you know exactly what it is. PUT input code > be JSON, multipart mime, a file or a whatever the dev wants. > That's not necessarily

Re: [PHP-DEV] New Standardized HTTP Interface

For the umpteenth time, *in what situation must you PUT multipart/form-data or multipart/x-www-form-urlencoded only to treat it, semantically, as a POST*? Which UA cannot send a POST? It's like we're completely upside down on this thread. If you're PUTing such POSTful content-types for any reas

Re: [PHP-DEV] New Standardized HTTP Interface

On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman wrote: > For the umpteenth time, *in what situation must you PUT > multipart/form-data or multipart/x-www-form-urlencoded only to treat it, > semantically, as a POST*? Which UA cannot send a POST? It's like we're > completely upside down on this t

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 5, 2014, at 10:00 PM, Sherif Ramadan wrote: > > > > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote: > > > > Easy - you have no idea what the input type is from PUT without checking the > incoming type. With POST, you know exactly what it is. PUT input code be > JSON, multipar

Re: [PHP-DEV] New Standardized HTTP Interface

On Wed, Nov 5, 2014 at 10:53 PM, Will Fitch wrote: > > > On Nov 5, 2014, at 10:00 PM, Sherif Ramadan > wrote: > > > > > > > > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote: > > > > > > > > Easy - you have no idea what the input type is from PUT without checking > the incoming type. With POS

Re: [PHP-DEV] New Standardized HTTP Interface

> The HTTP specification doesn't restrict how the request body is encoded > based on the request verb. I never said it did... please don't put words in my mouth. As Will notes, you're sidestepping the point, which standards-savvy people have been driving at for years: the semantic differences (==

Re: [PHP-DEV] New Standardized HTTP Interface

> Nowhere did I suggest that the request verbs themselves (i.e. PUT and POST) > have the same intent. Just > that the handling of multipart-form data is not specific to either one of > those verbs. Define "handling." :/ "Handling" as in "interpreting multipart/form-data as key-value pairs": a sp

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 2:44 AM, Sanford Whiteman wrote: > > The HTTP specification doesn't restrict how the request body is encoded > > based on the request verb. > > I never said it did... please don't put words in my mouth. > > As Will notes, you're sidestepping the point, which standards-savvy

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman wrote: > > Nowhere did I suggest that the request verbs themselves (i.e. PUT and > POST) have the same intent. Just > > that the handling of multipart-form data is not specific to either one of > > those verbs. > > Define "handling." :/ > Specific

Re: [PHP-DEV] New Standardized HTTP Interface

> Specifically, parsing the form data and populating it somewhere accessible > to the user as it is today in $_POST and making any binary upload available > in $_FILES or some other fashion. Ideally, making handling PUT more > consistent with the way PHP handles POST. OK, the first definition: "ha

Re: [PHP-DEV] New Standardized HTTP Interface

> PUT is not intended to necessarily store the request entity body on the file > system. Its intention is to store the entity body at the request URI. I never said it was. I used the expression "store at the URI" about 10 ten times on this topic. You are arguing in bad faith by putting words in

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman wrote: > > > > First of all, RFC 1867 is not a standard. It's an experimental protocol > > definition. > > Oh nonsense. You know very well that RFC 1867 conformance is an > industry standard for file uploading When 2388 says "originally set > out

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 4:56 AM, Sanford Whiteman wrote: > > PUT is not intended to necessarily store the request entity body on the > file > > system. Its intention is to store the entity body at the request URI. > > I never said it was. I used the expression "store at the URI" about > 10 ten ti

Re: [PHP-DEV] New Standardized HTTP Interface

Prove I "believe a multipart/form-data mime cannot be sent along with a PUT request" using messages I have sent to this list.  You are basically lying for effect at this point. I never said that, took pains to explain that I am not saying that, gave examples utterly to the contrary... yet you ma

Re: [PHP-DEV] New Standardized HTTP Interface

Hi! > Again, I think you're oversimplifying the problem. For one, you don't know > that the payload is JSON unless you check the Content-type header yourself, > and you really shouldn't have to since PHP could easily do this for you. Sure, PHP could easily do this, or any other one specific use c

Re: [PHP-DEV] New Standardized HTTP Interface

> On 7 Nov 2014, at 00:53, Stas Malyshev wrote: > > Hi! > >> Again, I think you're oversimplifying the problem. For one, you don't know >> that the payload is JSON unless you check the Content-type header yourself, >> and you really shouldn't have to since PHP could easily do this for you. > >

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 7:53 PM, Stas Malyshev wrote: > Hi! > > > Again, I think you're oversimplifying the problem. For one, you don't > know > > that the payload is JSON unless you check the Content-type header > yourself, > > and you really shouldn't have to since PHP could easily do this for y

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds wrote: > > > On 7 Nov 2014, at 00:53, Stas Malyshev wrote: > > > > Hi! > > > >> Again, I think you're oversimplifying the problem. For one, you don't > know > >> that the payload is JSON unless you check the Content-type header > yourself, > >> and y

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 7, 2014, at 12:16 AM, Sherif Ramadan wrote: > > On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds > wrote: > >> >>> On 7 Nov 2014, at 00:53, Stas Malyshev wrote: >>> >>> Hi! >>> Again, I think you're oversimplifying the problem. For one, you don't >> know

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote: > > Sherif - I’m just going to be straight here. I haven’t seen support for > your proposal at all in this thread. You continue to try and make this > case, but it continues to be shot down with absolutely valid issues, and > your only responsiv

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 7, 2014, at 12:38 AM, Sherif Ramadan wrote: > > > > On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch > wrote: > > Sherif - I’m just going to be straight here. I haven’t seen support for your > proposal at all in this thread. You continue to try and make this c

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Nov 7, 2014 at 12:47 AM, Will Fitch wrote: > > On Nov 7, 2014, at 12:38 AM, Sherif Ramadan > wrote: > > > > On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote: > >> >> Sherif - I’m just going to be straight here. I haven’t seen support for >> your proposal at all in this thread. You con

Re: [PHP-DEV] New Standardized HTTP Interface

Hi! > makes user land code more readily equipped to enable the user to do that > handling. In the same way that it does for POST. This creates some more Well, for POST PHP actually parses the data - url encoding, form encoding, files, etc. - and puts it into the data structure. For generic REST c

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Nov 7, 2014 at 4:49 PM, Stas Malyshev wrote: > Hi! > > > So the question here is how common is the case of PUT+mulitpart/form-data? > Well, that's what I'm trying to establish. Based on the information I have available, there have been a few dated bug reports asking for this. There are

Re: [PHP-DEV] New Standardized HTTP Interface

On 6 November 2014 00:31:18 GMT, Andrea Faulds wrote: > >> On 5 Nov 2014, at 22:29, Sherif Ramadan >wrote: >> >> From all the people I've spoken with that have a problem with >handling PUT >> requests in PHP, it seems that they'd rather have PHP populate >> $_FILES/$_POST automatically in this c

Re: [PHP-DEV] New Standardized HTTP Interface

On 09/11/2014 15:10, Rowan Collins wrote: On 6 November 2014 00:31:18 GMT, Andrea Faulds wrote: On 5 Nov 2014, at 22:29, Sherif Ramadan wrote: From all the people I've spoken with that have a problem with handling PUT requests in PHP, it seems that they'd rather have PHP populate $_FILES/