This seems like quite an odd thing to be happening, but I'm getting 404 responses but the pages are still displaying as expected.
I do have a slightly odd setup on this server, as we're running HHVM for PHP pages and using Varnish as we need to direct some of the pages to our old server.
We're running Drupal on this server and it seems to work fine except the 404 response seems to be stopping the login form from working.
I was going to add some images to show what's going on, but unfortunately don't have enough reputation....
here's the what we get from a GET -Sed request
pete#pete-work ~ $ GET -Sed http://beta.newint.org/user
GET http://beta.newint.org/user
404 Not Found
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Wed, 27 May 2015 15:14:23 GMT
Via: 1.1 varnish
Age: 0
Server: Apache
Vary: Accept-Encoding
Content-Language: en
Content-Type: text/html; charset=utf-8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Client-Date: Wed, 27 May 2015 15:14:23 GMT
Client-Peer: 178.79.141.247:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
ImageToolbar: false
Link: <http://beta.newint.org/user>; rel="canonical",<http://beta.newint.org/user>; rel="shortlink"
Title: User account | Site-Install
X-Generator: Drupal 7 (http://drupal.org)
X-Meta-Charset: utf-8
X-Meta-Generator: Drupal 7 (http://drupal.org)
X-Meta-Viewport: width=device-width, maximum-scale = 1.0
X-Powered-By: HHVM/3.7.0
X-Varnish: 1786764394
And then bypassing varnish and going straight to apache
pete#pete-work ~ $ GET -Sed http://beta.newint.org:8080/user
GET http://beta.newint.org:8080/user
404 Not Found
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Wed, 27 May 2015 15:14:31 GMT
Server: Apache
Vary: Accept-Encoding
Content-Language: en
Content-Type: text/html; charset=utf-8
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Client-Date: Wed, 27 May 2015 15:14:32 GMT
Client-Peer: 178.79.141.247:8080
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
ImageToolbar: false
Link: <http://beta.newint.org:8080/user>; rel="canonical",<http://beta.newint.org:8080/user>; rel="shortlink"
Title: User account | Site-Install
X-Generator: Drupal 7 (http://drupal.org)
X-Meta-Charset: utf-8
X-Meta-Generator: Drupal 7 (http://drupal.org)
X-Meta-Viewport: width=device-width, maximum-scale = 1.0
X-Powered-By: HHVM/3.7.0
Any ideas?
Turns out this was simply due to mod_rewrite not being enabled.
Related
We migrated our LAMP Ubuntu 16.04 (Apache 2.4.7) to a new one with Ubuntu 20.04 (Apache 2.4.41).
Both with a drive mounted on /var/www/intranet/onyar.
With the new one, if I download a file from this mounted drive it's corrupted. With the old one it works. If I download with the old server it's ok. If I access via samba it's ok.
http://newserver/intranet/onyar/test.xls => CORRUPTED
http://oldserver/intranet/onyar/test.xls => OK
\\newserver\root\var\www\intranet\onyar\test.xls => OK
So it seems a problem between Apache and mounted drive? If I try it with a file outside mounted drive (http://newserver/intranet/test.xls) it works OK.
I tested it with txt, office type and PDF files, all corrupted. HTML files works!
I put a simple 'test.txt' file with the string 'hola' inside and I open it with 'http://newserver/intranet/onyar/test.txt' the browser give me this:
Last-Modified: Thu, 12 Nov 2020 09:38:46 GMT
ETag: "4-5b3e5adb1be88"
Accept-Ranges: bytes
Content-Length: 4
Cache-Control: max-age=1209600
Expires: Thu, 26 Nov 2020 09:40:37 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain
holad_ip = dnsResolve(host);
if (isInNet(resolved_ip, "127.0.0.1", "255.255.255.255") || isInNet(resolved_ip, "172.16.0
In fact, if i Ctrl+F5 the string after hola (d_ip = ...) changes sometimes:
Last-Modified: Thu, 12 Nov 2020 09:38:46 GMT
ETag: "4-5b3e5adb1be88"
Accept-Ranges: bytes
Content-Length: 4
Cache-Control: max-age=1209600
Expires: Thu, 26 Nov 2020 09:57:01 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain
holar.</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at 10.80.160.178 Port 80</address>
</body></html>
p>The document h
Last-Modified: Thu, 12 Nov 2020 09:38:46 GMT
ETag: "4-5b3e5adb1be88"
Accept-Ranges: bytes
Content-Length: 4
Cache-Control: max-age=1209600
Expires: Thu, 26 Nov 2020 09:57:01 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain
holaIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document ha
These endings seems to be from other files! Like Apache don't know when is the file ending and puts there some other stuff...
Reference:
fstab: //onyar/dades /var/www/intranet/onyar cifs credentials=/root/.smbcredentials,file_mode=0775,dir_mode=0775,auto 0 0
It seems that I'm affected by this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821
For me the solution is putting this in /etc/apache2/apache2.conf:
<Directory "/var/www/intranet/onyar">
EnableMMAP Off
</Directory>
I have configured apache http with some cache settings. However, it does not seem to work properly and the browser seems to keep fetching the file as if it's not cached.
I tried to debug it by fetching the header.
$ curl -skI https://whatever-url-it-is/some-script.js
HTTP/1.1 200 OK
Date: Sun, 15 Sep 2019 05:35:08 GMT
Server: Apache/2.4.39 (Amazon) OpenSSL/1.0.2k-fips PHP/5.6.40
Last-Modified: Sun, 02 Jul 2017 10:52:25 GMT
ETag: "152ba-5535372162c40"
Accept-Ranges: bytes
Content-Length: 86714
Cache-Control: max-age=2592000, public
Expires: Tue, 17 Sep 2019 05:35:08 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/javascript
The Cache-Control header seems to be correct. The Expires header looks a little odd but according to this page (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires) the Expire will be ignored given that Cache-Control is there.
What else can I do to debug this issue? Any idea is very well welcome. Thanks
Never mind. I didn't realized that "Disable Cache" was turned on in Chrome. User error :-)
https://api-staging-weld.freetls.fastly.net/scripts/customdomain_weld.19f3e9ec.js
The error I get in Google Search Console is Temporarily unreachable with no further explanation. I think it's something with my http headers but can't figure out which one. Here they are:
accept-ranges: bytes
access-control-allow-origin: *
age: 4905
cache-control: public, max-age=31536000
content-encoding: gzip
content-length: 29990
content-type: application/javascript; charset=UTF-8
date: Fri, 20 Apr 2018 12:46:37 GMT
etag: W/"1a018-162e269bfe0"
last-modified: Fri, 20 Apr 2018 09:36:44 GMT
server: Cowboy
status: 200
vary: Accept-Encoding
via: 1.1 vegur
via: 1.1 varnish
x-cache: HIT
x-cache-hits: 1
x-powered-by: Express
x-served-by: cache-bma7030-BMA
x-timer: S1524228398.925110,VS0,VE6
What's wrong or what am i Missing?
I'm experimenting a very strange issue: using apache-2.2.25 on an Arch Linux server I get a truncated HTTP header in response, but only under windows machines.
I left untouched the httpd.conf file and I have created a file /srv/http/index.html with inside Hello.
With a web browser on a Linux machine I get correctly visualized the hello page, but under Windows I get
.1 200 OK Date: Fri, 15 Nov 2013 08:44:28 GMT Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/1.0.1e DAV/2 Last-Modified: Fri, 15 Nov 2013 08:15:09 GMT ETag: "27c-a-4eb32cbf8b950" Accept-Ranges: bytes Content-Length: 10 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Hello
It seems that the http header is truncated for the first characters (HTTP/1).
Have you got any advices?
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/xml; charset=utf-8
Expires: Tue, 06 Dec 2011 21:42:35 GMT
ETag: 28
Vary: *
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Tue, 06 Dec 2011 21:42:24 GMT
Content-Length: 258
I am building the expiration date myself and setting it, yet it still won't cache. I am using SqlDependency with this, but what I want for it to do is hold it in cache for say...30 minutes, then after 30 sql cache comes into play.
First thing that I notice is "Cache-Control: private". As long is it private it won't be cached by proxies and I'm not sure all the browsers will cache it.