Bug #10383 Updated: Receiving an HTTP PUT, rather than sending one

ID: 10383 Updated by: derick@php.net Reported By: matt@kurzweiltech.com -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: RH Linux PHP Version: 4.0.3pl1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: ------------------------------------------------------------------------ [2001-04-18 15:22:09] matt@kurzweiltech.com I have been trying to use PUT method support, as described in the PHP manual in the section "Handling File Uploads." The documentation says that when the request type is PUT, the body of the request is saved in a temporary file (in the directory specified in php.ini), and the name of the file is saved in a variable called $PHP_PUT_FILENAME (I tried $PHP_UPLOAD_FILE_NAME too, there is an inconsistency in the documentation, but neither worked anyway). As the documentation says, I put a line in httpd.conf (I am using apache 1.3.12) that says: Script PUT /path/to/myscript.php This works great...all PUT requests are getting redirected to my script. I know this, because the other parts that don't deal with the file are getting executed, and I was able to send HTML back to the client in an "echo" statement. Now, the value of the variable $PHP_PUT_FILENAME is empty. I looked at various other bugs alluding to this issue, and made sure of a couple things: in php.ini, register_globals is on, and the temporary file directory for uploads is also set (to /tmp). I also tried $PHP_UPLOADED_FILE_NAME (which is in the documentation example), to no avail. I am using an HTTP/1.1 PUT, not HTTP/1.0 as someone else did in an earlier bug. Next, I searched through all of the most recent sources for PHP_PUT, PHP_UPLOAD, and other such things, and came up with nothing. Nowhere in the PHP source is there any mention of such a variable. In one of the other bugs mentioning this problem, somebody mentioned cURL as an alternative. cURL, as far as I understand, is a set of functions that allow you to *make* PUT requests (and many other types of requests), but do not allow you to *receive* PUT requests, which is what I am trying to do. I next tried to get at the raw data of the PUT directly, figuring perhaps the $HTTP_RAW_POST_DATA would have the data or fopen("php://stdin","rb") would, but neither worked. For the latter, PHP already reads all of stdin, so nothing is left over to read, and for the former, I'm not sure that the variable ever gets set (I read a couple of mailing list posts about trouble with the HTTP_RAW_POST_DATA variable, I don't think it exists anymore). Is there a published workaround somewhere? For simplicity's sake, I'm not including my php_info() dump in this submission, but I'll be happy to give you one if you want it. Any insight into this would be much appreciated. If receiving PUT requests is no longer supported, at what point was that support dropped? It would be cool to have the documentation in that section updated if it was in fact dropped. I know this is kind of an obscure problem from the perspective of the WWW, as only a couple browsers use PUT, but when developing applications it's a lot easier to use PUT because no encoding is involved. Please let me know if there is any more information you need from me. -Matt ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=10383&edit=1