I have written a web application that uses someone else's API that requires ETags. I have tried this code:
header("ETagbleh: whatever");
Which works perfectly. However, when I set this:
header("ETag: whatever");
Nothing happens. I have heard that it may be Apache blocking the sending of ETags, but I'm not sure. I've done a search for ETag in my apache2.conf and can't find anything to uncomment / remove, so I came here to ask.
So, how can I stop Apache blocking my headers?
Edit: I'm using Apache 2.2.22, and I assumed that the scripting language was irrelevant, given that PHP 5.4.4, which is what I'm using, can set any other header fine.
I've had the same problem.
A very popular way to remove ETags in Apache2 is adding the following configuration:
Header unset ETag
FileETag None
Remove the first config line, if you find it in your configuration.
A bit more difficult to find is mod_include causing the problem. By default the ETag-Header is removed by this module. But you can allow it by configuration. So add something like this:
<IfModule mod_include.c>
SSIETag on
</IfModule>
See here for more information.
Related
I've setup an NGINX box with PHP-FPM. Everything works great, but my requests to that box send an extra request header, like: http_a_xpto (yes, it starts with "http_", and I cannot change it).
For some reason, all the headers with underscore ( _ ) are ignored and not able to be captured on PHP $_SERVER var.
I've enable "underscores_in_headers on;" at http directive, and even at server directive, on NGINX config file.
It's something missing in my config??
Thanks!
Richard was right.
So, apparently it seems that only with "service nginx restart", that flag at HTTP directive, was loaded. For production environment, where you "normally" don't restart but reload, this might be an issue.
This is an output by experience since I did not find any information related with HTTP directive changes only work with restart. If anyone have a link explaining that, please share here.
Thanks!
I have a website on a lamp stack with little to no extra configuration other than FallbackResource /index.php present in my root .htaccess
When I load the root page (localhost ) in Chrome I receive
GET http://192.168.163.171/ net::ERR_INCOMPLETE_CHUNKED_ENCODING VM110:1
in the chrome console after about 10 seconds. If I attempt to follow the link at VM110:1 it takes me to the top of my inline Javascript.
More information / What I've tried
This does NOT occur on any other page but root
There are no 404's in the access log nor any other abnormal codes
There are no errors appearing in the apache error log.
The error does not occur in the latest version of IE or Firefox.
It caused a problem in both my local environment and hosted. The latter has absolutely no config changes and I expect to be a near default install.
When I remove the FallbackResource directive my page loads fine without the error
In index.php the root is treated no different than any other page.
This would all be a non-issue because everything loads properly BUT it prevents javascript relying on a finished page load from working.
Any further ideas on what is causing the problem or new things I can try? I've considered moving to just using mod_rewrite but this is much simpler.
Finally found the answer while working on another site:
Before FallbackResource directive be sure to add a DirectoryIndex directive with the same file. Haven't had time to research why but it fixed my issue. I blame it on a Chrome bug or possibly Chrome being super picky because no other major browser has an issue.
I fixed this error by removing the following lines from my php5filter.conf file in the Apache configuration:
<FilesMatch ".+\.ph(p3?|tml)$">
SetInputFilter PHP
SetOutputFilter PHP
</FilesMatch>
To add to Blaine's answer (as I can't yet comment):
I believe this is an Apache configuration issue, not specific to Chrome.
I recently experienced this issue, and noted the following effects in various clients, again only with the home page:
Chrome, as stated, displayed the ERR_INCOMPLETE_CHUNKED_ENCODING error, but also didn't display the page correctly. The page continued to "load" for another 5 seconds even after all the content was visible.
A simple CURL request outputted the error curl: (18) transfer closed with outstanding read data remaining. The full HTML appeared, followed by the error after a delay.
Firefox and IE initially displayed the page incorrectly, as with Chrome, and again had the ~5 second additional loading time. However, after this period, the page suddenly reformatted itself correctly. No errors were seen in the respective developer consoles.
The solution to set the DirectoryIndex to the same location as FallbackResource resolved this for all clients.
Edit: An alternative if using mod_rewrite is to use something like RewriteRule ^$ index.php which will avoid affecting all subdirectories.
I don't know whether this is expected behaviour of Apache or a bug.
In my json response '\n' causing the issue. So after removing it, issue has been solved.
I've googled the crap out of this problem and came up with nothing, so hopefully you guys can help.
Goal
Configure a reverse proxy (using Apache's mod_proxy) to enable access to an internal PHP application over the internet using mod_proxy_html to rewrite URLs in my application.
Problem Description
Consider landing.php with only this code:
redirect.php
and redirect.php with only:
<?php
header("Location:http://internal.example.com/landing.php");
?>
with this snippet from my httpd.conf
UseCanonicalName On
LoadFile /usr/lib64/libxml2.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so
<VirtualHost *:80>
ServerName example.com
<Proxy *>
Order deny,allow
Allow from all
AllowOverride None
</Proxy>
ProxyPass / http://internal.example.com/
ProxyPassReverse / http://internal.example.com/
ProxyHTMLLinks a href #Commenting out this line fixes the problem, but I need it for rewriting
ProxyHTMLEnable On
RequestHeader unset Accept-Encoding
</VirtualHost>
When I go to http://example.com/landing.php and click "redirect.php" it should take me back to the landing.php page. Instead, I get a "This connection was reset" in Firefox, or "No data received" in Chrome. (FYI, going to http://internal.example.com/redirect.php redirects correctly.)
The Question:
Why the redirect would fail going through the reverse proxy, and how can I fix this?
Hints
I've discovered a few things that could be helpful...
I know that if I comment out "ProxyHTMLLinks a href", this will work correctly. But obviously, this is the rewrite functionality I need.
I can also change the redirect.php page to the following, this works correctly:
<?php
header("Location:http://internal.example.com/landing.php");
?>
random text
I guess this text somehow does something to the page or HTTP headers that make mod_proxy_html (or more specifically ProxyHTMLLinks) operate differently than without it.
I can also change the redirect.php page to the following and have it work:
<?php
header("Location:http://internal.example.com/landing.php");
header("Content-Type:");
?>
This works because ProxyHTMLLinks, by default, is only applied to Content-Type text/html files. However, I don't want to have to hack all calls to header("Location:...") to make this work. I don't mind changing all the calls to header("Location:..."), assuming what I'm changing is correcting a problem, not creating a hack.
Lastly, I've done some packet sniffing on the reverse proxy server and discovered that the header("Location:...") sends a HTTP/1.1 302 Not Found to the reverse proxy server, but it doesn't pass this through to the browser requesting redirect.php. When I try one of the "solutions" above, the 302 is then passed from the reverse proxy server to the computer requesting redirect.php.
My understanding is that the Location header should go to the browser, and then the browser should request the new location passed back. So it is failing because the 302 doesn't make it to the browser...
FYI, I've tried looking at the error logs to see if mod_proxy_html is failing somewhere, but I don't see anything, though I'm open to specific suggestions with regards to logging, since I'm not 100% sure if I'm setting the logging up correctly.
Sorry this is so long, just trying to be as specific as possible.
Thanks in advance!
I figured out the problem. I needed to explicitly pass the charset in the header Content-Type for this to work.
This was accomplished by adding:
AddDefaultCharset utf-8
to my Apache config file. This globally fixed all calls to header("Location:...") without having to add header("Content-Type:") or header("Content-Type:text/html;charset=utf-8") to each one of them.
In short, what I'm saying that the mod_proxy_html's ProxyHTMLLinks causes a 302 Found to not be forwarded from the reverse proxy server to the client if a) the content-type is text/html (and thus ProxyHTMLLinks) applies, b) the charset is not set and c) your page has no content passed back.
In my opinion, this is a normal scenario. Pages which process form inputs often meet all three criteria.
It's possible that for some reason this is the intended functionality, and that I'm doing something else wrong, but I can't see what that would be. At least there is an elegant workout here in case anyone finds it useful.
I have been trying to flush the output of certain scripts to the browser on demand, but they do not work on our productions server.
For instance, I tried running the "Phoca Changing Collation tool" (find it on Google) and I don't see any output until the script finishes executing.
I've tried immediately flushing the buffer on other script that works fine on any server but this one using the following code:
echo "something";
ob_flush();
flush();
Setting "ob_implicit_flush(1);" doesn't help either.
The server is Apache 2.2.21 with PHP 5.2.17 running on Linux. You can see our php.ini file here if that will help:
http://www.smallfiles.org/download/1123/php.ini.html
This isn't the only problem we are having with the server ignoring in-script directives. The server also ignores timeout coding such as:
ini_set('max_execution_time', 900*60);
AND
set_time_limit(86400);
Script always times out at the php.ini default.
Doesn't seem to matter if script is executed in IE or Firefox.
Solved this mystery. Both of them.
To fix the output buffer problem, I needed to turn off gzip compression inside the .htaccess file, though I wish I could just do it in-script.
Here's what you should put in your .htaccess file:
<IfModule mod_gzip.c>
mod_gzip_on No
</IfModule>
SetEnv no-gzip dont-vary
To fix the script terminating without error, I checked my Apache log files and found it wasn't PHP but in the Apache configuration:
The timeout specified has expired: ap_content_length_filter: apr_bucket_read() failed
Had to increase the Apache timeout to prevent this error from making it look like my scripts were timing out. Enabling KeepAlive in Apache also helped to resolve the issue once and for all.
Hope this helps someone and thanks for everyone elses' help!
You could be loading an incorrect php.ini file, as it tends to change based on directory.
To check your loaded php.ini file, write: echo php_ini_loaded_file();, which will give you the directory it's in. see php.net
if that fails, see serverfault.com for the server stackexchange site.
I am having what I believe is a strange problem. I have several sites developed on the same hosting platform. All site seem to be fine except for one of them. The website is set up around 1 page (index.php) that retrieves the correct data to display from the database based on the path_info - this has worked for years - now on one site this has stopped working. By stopped working I mean it the page below now goes to a 404 error - I was under the impress that it should see the index.php as the script to use.
I believe this is an issue with htconfig or another file I don't have access to being misconfigured on the host's end. Perhaps someone can shed light on where I might direct them. My own htaccess file is completely empty:
wwww.testsite.com/index.php/page1
The above used to go to index.php and then using $_SERVER path_info retrieve page1 and get the contents associated with page1 from the database and display that on the page. Can someone confirm I am not going mad - that the above should go to index.php please? and perhaps too explain why the url is now seen as non-existent since it doesn't seem to be going to index.php but to page1. Thanks in advance for any advice.
Can someone confirm I am not going mad - that the above [wwww.testsite.com/index.php/page1] should go to index.php please?
Nope. That should look for a file called page1 in the directory index.php in the document root for www.testsite.com.
I think you used to have an .htaccess file that looked something like this:
RewriteEngine on
RewriteRule ^index.php(.*)$ index.php
Another possibility is that MultiViews were previously enabled and now not anymore. With MultiViews you also get the behavior you described. If it's allowed by the hoster, you can enable it by simply creating an .htaccess file containing:
Options MultiViews
If you put an .htaccess file with either one of abovementioned solutions in it in your document root, you can verify this.
In Apache, if you have AcceptPathInfo on anywhere relevant in the Apache config (including in .htaccess, if the server config allows it) and there's a file /index.php, then /index.php/stuff should indeed go to /index.php, and should set $_SERVER['PATH_INFO'] to "/stuff". The CGI script handler and mod_php* even do this by default, so it should just work unless it's explicitly turned off.
Either way, if it's currently off, you can turn it back on by adding AcceptPathInfo on to your .htaccess file, if AllowOverride FileInfo is set for the site.
I make no promises about other web servers, but PATH_INFO is part of the CGI spec, so i'd think most servers would have a similar setting.