The HTTP/1.1 RFC stipulates "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response." I know Apache honors the RFC but modules don't have to. My question is, does mod_php5 honor this?
The reason I ask is because I just came across an article saying that PHP developers should check this themselves with:
if (stripos($_SERVER['REQUEST_METHOD'], 'HEAD') !== FALSE) {
exit();
}
I googled a second and not much turned up, other than some people saying they try to strange things like mod_rewrite/redirect after getting HEAD requests and some old bug ticket from like 2002 claiming that mod_php still executed the rest of the script by default. So I just ran a quick test by using PECL::HTTP to run
http_head('http://mysite.com/test-head-request.php');
while having:
<?php error_log('REST OF SCRIPT STILL RAN'); ?>
in test-head-request.php to see if the rest of the script still executed, and it didn't.
I figure that should be enough to settle it, but want to get more feedback and maybe help clear up confusion for anyone else who has wondered about this. So if anyone knows off the top of their head (no pun intended) - or have any conventions they use for receiving HEAD requests, that'd be great. Otherwise, I'll grep the C source later and respond in a comment with my findings. Thanks.
The HEAD method is identical to GET
except that the server MUST NOT return
a message-body in the response.
That is why the check should not be performed. Clients should have confidence that HEAD requests process just the same as if a GET was issued (database connection, processing, etc...).
Addendum:
When performing
HEAD /test.php?a=3 HTTP/1.1
Host: somesite.com
PHP will still fill $_GET (and $_REQUEST) with the variables placed in the query string even though it was not a GET request. This allows compliance with the HEAD definition.
I just did a quick test with a PHP file, temp.php, which contains this portion of code :
<?php
echo "Hello, World!\n";
die;
Sending an HTTP GET request to that file gets me the content of the page :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:17:35 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Length: 14
Content-Type: text/html
Hello, World!
While sending an HTTP HEAD request doesn't :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:17:50 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Type: text/html
Not sure this is always true, though...
I remember a situation (some time ago ; was PHP 5.1) in which I've had to test myself, in the PHP code, if I was getting a GET or a HEAD request.
EDIT : After an additionnal test
I just did another test : my temp.php file now contains this :
<?php
file_put_contents('/tmp/a.txt', $_SERVER['REQUEST_METHOD'], FILE_APPEND);
var_dump($_SERVER['REQUEST_METHOD']);
die;
Sending an HTTP HEAD request, I get this :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:21:30 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Type: text/html
Connection closed by foreign host.
Here, no output.
BUT, looking at the /tmp/a.txt file :
$ cat /tmp/a.txt
HEAD
So : no output sent by the server doesn't mean that there is nothing done ;-)
Related
I'm using Apache 2.2 and PHP 7.0.1. I force chunked encoding with flush() like in this example:
<?php
header('HTTP/1.1 200 OK');
echo "hello";
flush();
echo "world";
die;
And I get unwanted characters at the beginning and end of the response:
HTTP/1.1 200 OK
Date: Fri, 09 Sep 2016 15:58:20 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/7.0.9
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
a
helloworld
0
The first one is the chunk size in hex (10 = A). I'm using Klein as PHP router and I have found that the problem comes up only when the HTTP status header is rewritten. I guess there is a problem with my Apache config, but I wasn't able to figure it out.
Edited: My problem had nothing to do with Apache but Nginx and chunked_transfer_encoding directive. Check the answer below.
This is how Transfer-Encoding: chunked works. The extra characters you're seeing are part of the encoding, rather than the body.
A client that understands the encoding will not include them in the result; a client that doesn't doesn't support HTTP/1.1, and should be considered bugged.
As #Joe pointed out before, that is the normal behavior when Chunked transfer enconding is enabled. My tests where not accurate because I was requesting Apache directly on the server. Actually, when I was experiencing the problem in Chrome I was querying a Nginx service as a proxy for Apache.
By running tcpdump I realized that Nginx was rechunking responses, but only when rewritting HTTP status header (header('HTTP/1.1 200 OK')) in PHP. The solution to sending Transfer-Encoding: chunked twice is to set chunked_transfer_encoding off in the location context of my Nginx .php handler.
Why do some web applications/servers/etc issue a non-standard, second, Status header. For example, I'm working with an existing application where, in addition to that HTTP protocal line, there's a second header named status
$ curl -I 'http://example.com/404'
HTTP/1.1 404 Not Found
//...
Status: 404 Not Found
//...
and a stock apache 404 doesn't include it
HTTP/1.1 404 Not Found
Date: Thu, 24 Jul 2014 13:16:28 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
Content-Type: text/html; charset=iso-8859-1
I'd write this off as one quirky application developer, but I've seen this behavior is other applications over the years, and the Wikipedia article on HTTP headers mentions this header, although it points out the header isn't included in RFC7230.
? "Status" is not listed as a registered header. The "Status-Line" of a "Response" is defined by RFC7230[23] without any explicit "Status:" header name.
Does anyone know the deal here? Is there some browser that needed this at some point? Still needs it? Is this some weird bit of SEO voodoo?
Is there any practical effect to including/not-including this field? Has there ever been?
(I'm specifically working with PHP, if that matters)
I am using a DocuSign API and have run into some issues.
When sending the data request to their server I am getting the following error:
SoapFault exception: [q0:InvalidSecurity] An error was discovered
processing the <Security> header ---> WSE065: Creation time of the
timestamp is in the future. This typically indicates lack of synchronization
between sender and receiver clocks. Make sure the clocks are synchronized
or use the timeToleranceInSeconds element in the microsoft.web.services3
configuration section to adjust tolerance for lack of clock synchronization.
I have looked all over their community forums and the only response I can find from their forum admin is this:
The message means that the client clock is wrong. The timezone might be set
incorrectly. If the SOAP request is timestamped too far in the future or in the
past, the server will reject it. We generally run into this error with mobile
apps since folks don't always have their devices set to sync to network time.
I checked my server time as well as my computer time to make sure everything is fine. My computer time is set to EST, and the server is set to CST. I have tried updated and synchronized my system clock on my computer as well as trying to adjust my timezone to CST to make sure they both match. I have also changed my computer time to GMT because that is what they say their server time is. I have also tried updating my server's clock since it seems to be the one that is a little bit off. (there seems to be like a 6 minute difference between my clock and the server clock).
I ran this command on the server:
sudo ntpdate ntp.ubuntu.com
Response:
27 Sep 08:51:41 ntpdate[18858]: step time server 91.189.94.4 offset -357.639332 sec
I also tried editing my grub configuration file on the server (/boot/grub/grub.conf). I tried adding different combinations of these params to the end of the kernel line:
clock=pit
acpi=off
noapic
As well as trying to update the hardware clock with this command:
hwclock=systohc
The soap headers are as follows:
This request was sent out at 10:41AM(my computer time [EST]), 9:47AM (my server time [CST]).
Request:
POST /api/3.0/api.asmx HTTP/1.1
Host: www.docusign.net
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.3.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.docusign.net/API/3.0/CreateEnvelope"
Content-Length: 116157
Response:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 1696
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 27 Sep 2012 14:41:13 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=7776000; includeSubDomains
If anyone has any thoughts as to what might be causing this error, or if anyone has any further advice on how to go about synchronizing my clocks, I would love to hear them.
Thanks in advance for your time and consideration.
I ended up contacting the company I am hosting my virtual server with and as it turns out it wasn't an issue with anything I have control over at all. It turned out that their hypervisor (virtual machine monitor - VMM) was having issues so when my server was synchronizing its time from it, my time was getting offset by about 7 minutes. Since the system clock of my server was being controlled by it, this also disallowed me from being able to set the time manually with this command:
date -s "27 SEP 2012 HH:MM:SS"
since the changes would just be superseded by the VMM.
I have a big problem.
I have some applications made on an unix based system, and I use PHP with cURL to post an XML question to an IIS server with asp.net.
Every time I ask the server something I get error:
HTTP/1.1 500 Internal Server Error
Date: Tue, 04 May 2010 07:36:08 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 3032
But if I ask same question on another server, almost identically to this one (BOTH configured by me) I get results like it should and the headers:
HTTP/1.1 200 OK
Date: Tue, 04 May 2010 07:39:37 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 9169
I tried everything, searched hundreds of forums, but i don't find anything.
In IIS logs I only get:
2010-05-04 07:36:08 W3SVC1657587027 80.xx.xx.xx POST /XML_SERV/XmlAPI.aspx - 80 - 80.xx.xx.xx Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1 500 0 0
any ideas where to look what is going on?
I forgot to mention! If I use an XML request software, and ask same question, it works.
Try reducing your asp page to the minimum, with the first try with an empty page. If this succeed, begin to add the real bits until it fails, so you can narrow the error.
I'm using PHP to redirect a page back to the previous page with the following:
header("Location: {$_SERVER['HTTP_REFERER']}");
This set of pages will only be used by internal users, so I'm not terribly concerned about the fact that the referer will not always be available.
The problem I'm running in to is that if the referer looks like http://subdomain.domain.com/test.php?id=13, the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13. Notice the additional .domain.com/ in the url.
I've tested by hardcoding the value, and it causes the problem as well. phpMyAdmin seems to suffer the same issue, but only on this particular server.
If this is not an SO question, please move accordingly.
EDIT: per #yaggo
test.php contains only header("Location: http://subdomain.domain.com/test2.php");
curl --head --referer 'http://subdomain.domain.com/' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Server: nginx/0.7.64
Date: Fri, 02 Apr 2010 17:21:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.2.12-pl0-gentoo
Location: .domain.com/test2.php
I've recreated both your programs on my server
once with
header("Location: http://subdomain.domain.com/some/place");
and once with
header("Location: {$_SERVER['HTTP_REFERER']}");
and both give the corret result
curl --head --referer 'http://subdomain.domain.com/some/place' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Date: Fri, 02 Apr 2010 17:48:54 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.2
Location: http://subdomain.domain.com/some/place
Connection: close
Content-Type: text/html
I'm using a different version of PHP and a different webserver, so there's two things to investigate.
It seems that your nginx configuration is causing the problems.
Its totally possible that nginx is modifying the response headers. This is not by default - you could have a configuration that is aimed for it to behave as a reverse proxy etc.
Have you tried testing the redirect on a nginx with its default configuration?
[...] the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13.
Can you isolate the problem a little bit more? Is that url exactly what is returned by PHP or is it how browser (Chrome?) sees it?
Can you check the actual headers e.g. with curl:
$ curl --head --referer 'http://your-referer' 'http://your-page/'
header("Location: ".$_SERVER['HTTP_REFERER']);
Edited:
Check you .htaccess settings or if no solution found u can use preg_replace to remove that last ".domain.com"
but it looks that is a not a php error.
OR use javascript to get the referer address...
then use window.location.href = url; to redirect ...