Let me be clear: I'm not suggesting we should ignore useful functionality because of poor design decisions made in the past but I am saying that we should avoid compounding those mistakes by building on top of them. Would a $_PUT superglobal be helpful? Sure. But is it a good solution to underlying problem? Not really.
> it's a common problem; I can agree with this -- PUT's use is widespread and adding support is probably sensible. That said, your other arguments don't hold much water: > I did originally. An inability on your part to write working code doesn't equate to "PHP should implement this for me" > it would a require very wide set of test cases to ensure it won't break in some random edge case The need for testing doesn't diminish if the parsing is implemented in C vs. PHP > Multipart support for PUT was literally the only issue I personally encountered when writing a public REST API in PHP. Are you sure you didn't need it for your RESTful PATCH requests too: http://tools.ietf.org/html/rfc5789 And what happened when you implemented Expect: 100-continue headers in your RESTful requests? Basically, if you're suggesting that adding $_PUT would solve all of PHP's problems with full HTTP protocol support then I can't agree. On Tue, Sep 24, 2013 at 11:42 AM, <catch.d...@gmail.com> wrote: > Thanks Daniel. My thoughts on your response: > > Where does it stop? This is the problem I see with all the requests to > support for PUT similarly to POST. > > Right here with PUT. Providing a RESTful interface is *hugely* common and > $_PUT is the only one missing to complete REST. PUT is the glaringly > obvious one missing. > > You could easily write a parser in userland to accomplish the same thing. > > I did originally. But it became obvious that (a) it's a common problem; > (b) being non-trivial, it would a require very wide set of test cases to > ensure it won't break in some random edge case; and (c) the functionality > already exists for POST. > > Other languages (Ruby, for example) make REST very easy. Multipart support > for PUT was literally the only issue I personally encountered when writing > a public REST API in PHP. > > Dave. > > On 24/09/2013, at 7:59, Daniel Lowrey <rdlow...@gmail.com> wrote: > > > In short, in order to provide a proper REST service that supports > multipart > > form data, we need someway to parse data sent via PUT (data is available > > via php://input, but it needs to be parsed). > > Multipart entity parsing is fairly straightforward. You could easily write > a parser in userland to accomplish the same thing. Unless you're doing a > very high volume of CRUD via PUT the performance hit of doing this in > userland should be negligible. > > That said, I think exposing a function to do this could be a useful > addition, and since PHP already has code to parse these entities for POST > requests it shouldn't be too much work to expose that via something like a > new mime_multipart_parse() function. It's not really a priority for me, but > you can probably find someone to work on this for you if you're not a C > person. > > The bigger issue here is that the superglobals are a leaky abstraction. > Any HTTP request method is allowed to have an entity body, so should we > also create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used > request methods? Where does it stop? This is the problem I see with all the > requests to support for PUT similarly to POST. PHP web SAPIs support 95% of > the HTTP use-cases people have, but the abstractions break down after that > and continuously bolting on support for individual scenarios beyond that > would be a mistake IMO. > >
