PHP sending different headers on different hosts - nginx

I have two identical instances of an application - one on my local machine the other one on a VPS.
The problem ist, that my local instance sends the expected headers:
[rico#local]$ curl -I app.local
HTTP/1.1 302 Found
Server: nginx/1.6.0
Content-Type: text/html
Connection: keep-alive
X-Powered-By: PHP/5.5.14
Set-Cookie: PHPSESSID=9sh2e9uo9b56sdvhrruakigvd7; path=/
Cache-Control: max-age=0, must-revalidate, no-store, nocache, private
Date: Thu, 14 Aug 2014 14:51:30 GMT
Location: /login
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Whereas the instance on the VPS send some other (wrong) headers:
[rico#local]$ curl -I app.vps
HTTP/1.1 302 Found
Server: nginx/1.6.0
Content-Type: text/html
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.3
Set-Cookie: PHPSESSID=me5h90pj59g0rh62rjlghtjsi0; path=/
Cache-Control: max-age=315360000
Date: Thu, 14 Aug 2014 14:52:40 GMT
Location: /login
Expires: Thu, 31 Dec 2037 23:55:55 GMT
What / who might be rewriting my headers?

Related

How to tell Chrome not use local cache prematurely

The page (just a static .html) is served with the following headers:
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Jul 2015 02:59:37 GMT
Content-Type: text/html; charset=utf-8
Last-Modified: Wed, 29 Jul 2015 02:53:23 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Content-Encoding: gzip
Then, I close the tab, open the page again (by typing the url manually) and get the next response:
HTTP/1.1 304 Not Modified
Server: nginx
Date: Wed, 29 Jul 2015 02:58:45 GMT
Last-Modified: Wed, 29 Jul 2015 02:53:23 GMT
Connection: keep-alive
ETag: "55b84023-1ad"
I repeat it several times and then Chrome stops requesting it from the server and serves directly from its cache.
Status Code:200 OK (from cache)
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Wed, 29 Jul 2015 02:59:56 GMT
Last-Modified:Wed, 29 Jul 2015 02:53:23 GMT
Server:nginx
Vary:Accept-Encoding
Is there a way (server side) to tell Chrome not to do that, but respect HTTP caching headers on every request?

cURL response missing Location field

I am curling to a server that I own and getting a response. But this response is missing a Location field. Can anyone help me figure out why this is happening?
This is the curl:
curl -I http://example.server.net/
And this the the response I get:
HTTP/1.1 200 OK
Date: Fri, 18 Jul 2014 15:08:53 GMT
Server: Apache/2.2.22 (Ubuntu)
Content-Length: 15
Vary: Accept-Encoding
Content-Type:
As you can see there is no Location field that responds with something like:
Location: http://example.server.net
I know it is a valid field from other curls. I am looking for reasons why some basic fields might not be shown and possible solutions
Thanks!
You will get Location header when response code is 3xx.
For example:
$ curl -I http://g.cn
HTTP/1.1 301 Moved Permanently
Location: http://www.google.cn/
Date: Fri, 18 Jul 2014 15:29:10 GMT
Expires: Fri, 18 Jul 2014 15:29:10 GMT
Cache-Control: private, max-age=2592000
Content-Type: text/html; charset=UTF-8
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 80:quic,80:quic

IIS http response header content expiration not displaying

I am trying to set the http response header for content expiration. I would assume the response header from the server would display this, however I have been unable to figure out how this is transmitted back to the calling application.
When I set the "Web content expiration" to expire after 30 minutes, the response is still displaying the following.
Content-Length: 4691
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Nov 2012 20:38:39 GMT
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
What I am expecting is something similar to the following:
Connection: close
Accept-Ranges: bytes
Content-Length: 689
Cache-Control: max-age=1800
Content-Type: text/html
Date: Thu, 08 Nov 2012 00:36:19 GMT
ETag: "f94ce92e467cc1:0"
Last-Modified: Wed, 31 Aug 2011 13:43:48 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET

When playing an MP3 from cache, Firefox displays "File not found"

Calling my script should play audio in your browser of type audio/mpeg.
The audio plays in Firefox when force-refreshing, but upon the second call the audio does not play.
The script tries to set Cache-Control to stop caching. Yet the browser seems to be caching, and is not able to retrieve the audio content.
On first call, my browser receives:
HTTP/1.1 200 OK
Date: Thu, 08 Mar 2012 20:21:16 GMT
Server: Apache
X-Powered-By: PHP/5.3.8
Cache-Control: public, must-revalidate, max-age=0, max-age=86400
Pragma: no-cache
Accept-Ranges: bytes
Content-Disposition: inline; filename=627.mp3
Content-Transfer-Encoding: binary
Content-Length: 16299
Last-Modified: Wed, 22 Feb 2012 21:58:33 GMT
Expires: Sat, 10 Mar 2012 20:21:16 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
On second call, though, it receives:
HTTP/1.1 304 Not Modified
Date: Fri, 09 Mar 2012 20:21:54 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Expires: Sat, 10 Mar 2012 20:21:54 GMT
Cache-Control: public, must-revalidate, max-age=0, max-age=86400
X-Pad: avoid browser bug
... and the audio does not play.
Any hints on why this audio does not play upon the second call?

How to crawl a wordpress blog?

I write a c program to crawl blogs. It works well until it meets this blog: www.ipujia.com. I send the HTTP request:
GET http://www.ipujia.com/ HTTP/1.0
to the website and get the response as below:
HTTP/1.1 301 Moved Permanently
Date: Sun, 27 Feb 2011 13:15:26 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4
Perl/v5.8.8
X-Powered-By: PHP/5.2.14
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Sun, 27 Feb 2011 13:15:27 GMT
Location: http://http/www.ipujia.com/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
This is strange because I cannot get the index page following the Location. Does anyone have any ideas?
The Location field in the response contains a malformed URI.
Location: http://http/www.ipujia.com/ (notice the protocol error)
Should be
Location: http://www.ipujia.com/
Unless you are in control of the server there is little you could do here.
To solve it could you not parse the "Location" response and attempt to extract a valid URI from the it?

Resources