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?
Related
Opening same URL from browser, and the server returns below header.
Repeating again, why it always give HTTP 200, instead of 304.
Any idea?
HTTP/1.1 200 OK Server: Cowboy Connection: keep-alive X-Powered-By:
Express Content-Type: text/html Cache-Control: public, max-age=600
Date: Sat, 07 Nov 2015 04:41:50 GMT Transfer-Encoding: chunked Via:
1.1 vegur
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?
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?
So, I wrote a program than is supposes to connected to a server, and it returns the time. It works on my server, but when I tried to use it on another server, it responses oddly. Here is the response from my server:
HTTP/1.1 200 OK
Date: Tue, 07 Jan 2014 00:06:20 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u5
Set-Cookie: PHPSESSID=jlscamqbddtqibf9j7m0fu27p5; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 6
Connection: close
Content-Type: text/html
4:06pm
which works great. Now here is the response from the other server (doesn't work):
HTTP/1.1 200 OK
Date: Tue, 07 Jan 2014 00:06:34 GMT
Server: Apache
Set-Cookie: PHPSESSID=krlqmoqgpiqm9b9u27agup53c7; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
6
4:06pm
0
As you can see I'm getting some weird stuff before and after the expected response. The code on the server is exactly the same. And the code on the Arduino is the same except for the a couple strings.
Here is a pastebin of the code I am using: http://pastebin.com/TFF5h2Gw
Sorry there aren't a lot of comments and it's kinda jumbled together. I omitted a little bit of code that is used by other stuff that I haven't even gotten to test yet because I can't even get the time.
What you are seeing is a chunk-encoded response. That is okay as all HTTP/1.1 capable clients are supposed to understand this transport encoding. What is wierd is that the server is not explicitly marking the response as being chunk-encoded (This is usually done via the Transer-Encoding: chunked header).
A quick way to get rid of this is to issue a HTTP/1.0 request.
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