Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

I'm coding a Service Oriented system, and according to REST principles, I should be able to call a service with a PUT or DELETE method.

For example, using AJAX, in JavaScript I would write something like:

objeto= new XMLHttpRequest();
objeto.open("PUT", "my_own_service.php", true);
objeto.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8");
objeto.onreadystatechange= some_function_of_mine;
objeto.send("a_string_like_field=value&field2=value2"); 

but then, my_own_service.php would have no way of getting to the PUT parameters! With POST or GET methods, you can use the $_POST and $_GET (and even $_REQUEST) arrays, but there are no $_PUT or $_DELETE equivalent arrays.

Note, however, that this is *not* just an AJAX problem; if you require a PHP service from within another PHP service, you would code something like:

$ch= curl_init();
curl_setopt($ch, CURLOPT_URL, "my_own_service.php");
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS, "a_string_like_field=value&field2=value2");
$result= curl_exec($ch);
curl_close($ch);

Of course, this points out yet ANOTHER problem... there is no CURLOPT_PUTFIELDS! Since the format is the same, I assume my way should work, but I cannot even get to test it until I have a way of getting to the PUT parameters from within PHP.

So, to resume it all, it seems to me:

* there should be $_PUT and $_DELETE arrays

* curl should support CURLOPT_PUTFIELDS, *or* make it clearer that CURLOPT_POSTFIELDS is to be used.

Hope I was clearer this time!
Best regards,
Federico Kereki

I'd like to take this on.  I too have come up against a similar issue 
and I know of another developer who would be appreciative of it.  

So I propose I make a patch that adds support for PUT, DELETE and HEAD 
(for completeness) super globals.  

Per RFC 2616 PUT is similar to post and can have data both in the URI 
and the body of the request.  DELETE and HEAD are like GET.  Since there 
is already support for POST data in the sapi code and php_variables.c 
has treat_data() for handling GET.  It seems it should be relatively 
simple to extend for the new variables.

What do you think?

If the only contents of the request body is the urlencoded "DELETE parameters" 
you can retrieve them by using file_get_contents("php://input"). It's not as 
clean as $_DELETE, but it's a workaround for now at least.

I hit submit prematurely. Here's how to emulate $_DELETE:     
parse_str(file_get_contents('php://input'), $_DELETE);

Parsing "php://input" is *not* a workaround because it fails on multipart/encoded 
input. Which is a common method to send data (and also the only way to send 
files).

See similar/duplicate bug entry here: https://bugs.php.net/bug.php?id=55815

Is this still relevant?

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

This issue is still not solved, and the rationale for its solution is still valid.

Hi,

I am a PHP Application Developer

I would appreciate if there is support for $_PUT, $_DELETE superglobals similar to $_GET and $_POST since these 4 are the major http request methods

I know of the workaroung of parsing php://input stream

But it doesnt look good on a highly mature scripting language as PHP as there should be a native support for PUT and DELETE requests

In php 7.4 still not solved. 

This was very helpfull for develop REST APIs and similars.

There is any option to add this in the future? 

Is this problem at least being debated by PHP core developers? Or is it not even being valued?

This feature likely requires the RFC process[1], because it is
obviously controversial[2].  Feel free to start the RFC process;
for the time being, I'm suspending this ticket.

[1] <https://wiki.php.net/rfc/howto>
[2] <https://externals.io/message/77972>

I Think that the implementation should be done... or at least, create functions to get the correct input and the correct query for us, developers to assign instead of blindly follow php://input