|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #10383 Receiving an HTTP PUT, rather than sending one
Submitted: 2001-04-18 15:22 UTC Modified: 2002-06-02 13:33 UTC
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (50.0%)
From: matt at kurzweiltech dot com Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 4.0.3pl1 OS: RH Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: matt at kurzweiltech dot com
New email:
PHP Version: OS:


 [2001-04-18 15:22 UTC] matt at kurzweiltech dot 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.



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-02 13:33 UTC]
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

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.

 [2002-07-17 11:02 UTC] groenendijk at frg dot eur dot nl
I'm having the same problem over here (used to work fine in php3.0.18):
Redhat 7.3
Apache updated rpm: apache-1.3.23-14

Script PUT /put.php3

script snippet:
if (isset($PHP_AUTH_USER) && isset($PHP_AUTH_PW)) {
  syslog(5,"Authorized, trying authenticated FTP");

syslog output:
Jul 17 16:59:59 spinoza put.php3: Started
Jul 17 16:59:59 spinoza put.php3: Unauthorized, requesting authentication
Jul 17 16:59:59 spinoza put.php3: Started
Jul 17 16:59:59 spinoza put.php3: Authorized, trying authenticated FTP
Jul 17 16:59:59 spinoza put.php3: PHP_PUT_FILENAME=, REQUEST_URI=/lia/test.html
Jul 17 16:59:59 spinoza[22726]: SERVER_NAME
Jul 17 16:59:59 spinoza[22726]: REQUEST_URI /lia/test.html

as you can see in the log, other variables are there, except for this one.

 [2004-10-05 11:03 UTC] alienmind at gmx dot net
same problem here. don't know what to do.
supposedly, in version 4.x, I am using, put's can be received by using 
fopen("php://stdin", "r");
but there comes nothing. all is right and the put itself looks like:

PUT http://x.x.x/xbel.xml HTTP/1.1
Host: x.x.x
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Length: 18516
Content-Type: text/xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>

i mean, what SHOULD a guy in my age do with php4.3.8 to get it working?
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 30 16:01:33 2024 UTC