Edit report at https://bugs.php.net/bug.php?id=37681&edit=1
ID: 37681
Comment by: catch dot dave at gmail dot com
Reported by: f_kereki at cs dot com dot uy
Summary: PUT and DELETE superglobals support
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: SUSE 10.0
PHP Version: 5.1.4
Block user comment: N
Private report: N
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2010-06-01 22:15:33] andreas dot s dot t dot jansson at gmail dot com
I hit submit prematurely. Here's how to emulate $_DELETE:
parse_str(file_get_contents('php://input'), $_DELETE);
------------------------------------------------------------------------
[2010-06-01 21:59:24] andreas dot s dot t dot jansson at gmail dot com
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.
------------------------------------------------------------------------
[2009-10-21 12:33:28] cyberspice at cyberspice dot org dot uk
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?
------------------------------------------------------------------------
[2006-06-03 13:43:51] f_kereki at cs dot com dot uy
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
------------------------------------------------------------------------
[2006-06-02 19:28:33] mike@php.net
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=37681
--
Edit this bug report at https://bugs.php.net/bug.php?id=37681&edit=1