In Chrome and Safari a remote image included on my site never seems to get requested with caching-friendly headers (If-Modified-Since, etc) despite the server returning the appropriate information. Local resources, on the other hand, are requested with these headers. In contrast Firefox requests the remote resources with caching-friendly headers.
This is for images on S3 though I don't think it's unique to S3...
Update: Here's the actual request I'm seeing via Chrome Resources panel.
Request URL:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
Request Method:GET
Status Code:200 OK
Request Headers
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Cache-Control:max-age=0
Referer:http://mobtest.s3.amazonaws.com/4MKHZL-114.png
User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4
Response Headers
Cache-Control:public, max-age=86400
Content-Length:4074
Content-Type:image/png
Date:Wed, 30 Jun 2010 12:15:42 GMT
ETag:"7e4739d5527ada6bb327f1e27ee656ef"
Last-Modified:Tue, 29 Jun 2010 13:40:08 GMT
Server:AmazonS3
x-amz-id-2:MKTS28Zu4zTsWFjXUTzvmRY214TO9LTKTxtgW1psWKa/JY2pnwmO9rxs8fyHd/O/
x-amz-request-id:F6047ADD0FD6D885
x-amz-version-id:O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp
Repeating the request doesn't lead to any additional headers being sent by Chrome (and as mentioned before, Safari). In contrast, quickly refreshing in Firefox gives me the following:
Status: 304 Not Modified
Response Headers
x-amz-id-2 IbhwfAP7FhIN7jtn2FrsjOkVZ8sIKJjv5llevKgw04y2xM+29GSFdGyQNXjiBaMY
x-amz-request-id 258F30A4CC2AC870
Date Wed, 30 Jun 2010 12:19:55 GMT
Cache-Control public, max-age=86400
Last-Modified Tue, 29 Jun 2010 13:40:08 GMT
x-amz-version-id O2OTsDbU4uKOwze7rbK_Do39U_Xhpnyp
Etag "7e4739d5527ada6bb327f1e27ee656ef"
Content-Type image/png
Content-Length 4074
Server AmazonS3
Request Headers
Host mobtest.s3.amazonaws.com
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
If-Modified-Since Tue, 29 Jun 2010 13:40:08 GMT
If-None-Match "7e4739d5527ada6bb327f1e27ee656ef"
Cache-Control max-age=0
Update 2: And now I see Chrome caching the content. Strange... I'm going to close this question and give Marc the answer.
If the server is sending back an "Expires" header that is somewhat far in the future, then the browser may be deciding that the content is still fresh enough in it's cache and that they don't even need to make a request to the server at all. You may want to review the headers being sent back from the server and ensure they are set to reasonable values. See ETag vs Header Expires for more information. Feel free to update your question with the actual URL or headers that are sent back from the server.
Related
I've inherited a website that contains about 100 audio files. The links to the files are relative links like this:
part 1
Back in the day those usually forced a download. Newer browsers now play the audio in browser. Except....
If the user comes to the site over https they are able to navigate the site and the html pages load, but the links to the audio files generate a 403 Forbidden error. Changing the protocol in the location http allows the mp3 to load and playback in the browser.
Why would the mp3 files be forbidden over https?
Is there a way to force the http protocol without having to make all the links absolute links? I notice the relative links "inherit" the protocol of the page they were loaded on. There isn't anything on any of these pages that need https so I wouldn't mind forcing all the parent pages to load over http....
This is a departmental site within a giant university. So I don't have access to the server, htaccess, or any of those kinds of tricks. All in browser, javascript, html solutions please.
UPDATE
I installed Firebug to view the headers and discovered that the audio plays fine in FireFox (on my mac). In Safari they load and play, but the controls don't show the progress or time, but they do play. And in Chrome they don't play at all.
I had also checked them on my PC at work and they don't play in IE9 (I know! Corporate IT, right?) or Chrome.
Here is what I get for headers in Firefox where the audio plays fine.
HTTP/1.1 200 OK
Date: Sat, 11 Apr 2015 15:39:04 GMT
Server: Apache
WWW: www3
Vary: X-Forwarded-Proto
Last-Modified: Tue, 16 Nov 2010 14:19:25 GMT
Etag: "78e935-d60ac-4952c3e68d540"
Accept-Ranges: bytes
Content-Length: 876716
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
GET /dept/area/language/stories/sounds/file.mp3 HTTP/1.1
Host: example.edu
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.edu/dept/area/language/stories.html
Cookie: _ga=GA1.2.829124232.1405280613; BIGipServerWWW-HTTP=1378527424.20480.0000; _gat=1
Connection: keep-alive
And these are what I get in Chrome.
Remote Address:128.122.119.202:443
Request URL:https://example.edu/dept/area/language/stories/sounds/file.mp3
Request Method:GET
Status Code:206 Partial Content
HTTP/1.1 206 Partial Content
Date: Sat, 11 Apr 2015 15:46:12 GMT
Server: Apache
WWW: www4
Vary: X-Forwarded-Proto
Last-Modified: Tue, 16 Nov 2010 14:19:12 GMT
ETag: "78e939-158dbc-4952c3da27800"
Accept-Ranges: bytes
Content-Length: 1
Content-Range: bytes 382271-382271/1412540
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg
GET /dept/area/language/stories/sounds/file.mp3 HTTP/1.1
Host: www.nyu.edu
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
DNT: 1
Referer: https://example.edu/dept/area/language/stories.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,es;q=0.6,hi;q=0.4,pt;q=0.2
Cookie: _ap_utmz=57748789.1416681263.3.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); _ap_utma=57748789.722895429.1387124094.1423327171.1425612794.7; __utma=57748789.194555315.1387124094.1423327171.1425612794.7; __utmz=57748789.1416681262.3.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); BIGipServerWWW-HTTP=1395304640.20480.0000; _gat=1; _ga=GA1.2.194555315.1387124094
Range: bytes=382271-382271
If-Range: "78e939-158dbc-4952c3da27800"
HTTP Request and Response Headers
Make sure to read about headers, mime types and content encodings.
You could try to utilise the Content-Disposition response header
An opportunity to raise a "File Download" dialogue box for a known MIME type with binary format or suggest a filename for dynamic content. Quotes are necessary with special characters.
Source: Wikipedia
Anyway your issue seems like a http header issue, could be compression as well. Take a look at your headers and whats different and troubleshoot from there. When you understood the problem, you can think of solutions.
Troubleshooting Tools
Use firebug or chrome developer tools to investigate. Fiddler Proxy to simulate different headers, since you have no access to your server.
File Permissions
Could be that SSL runs as another user or config on your server and the mp3 files have the wrong permissions or their parent directory. You need to check those, but since you have no server access you could be out of luck.
However, if SSL is not important to you just link to the files like so:
<a href="http://yourDomain.tld/folder/anotherFolder/file.mp3">
This will enforce the http protocol being used for the links. Most likely this results in the SSL chain being broken due to the mix in of http traffic into your ssl secured traffic. Therefore there's another alternative to achieve what you want:
Meta Refreshes
<meta http-equiv="refresh" content="3; URL=http://www.yourNonSSLDomain.tld/">
This will redirect to your non-SSL website where you can make sure to not mix https and http resources in your html document.
I've got an application where I'm using a text editor to insert images and banners etc. It gets the banner by calling an AJAX request to get the banner, then it compiles the JS.
I want a quick/easy way to cache the request. So I was hoping to just cache the response in the browser cache for 30 seconds.
So I'm trying to get it working in Chrome, but it keeps sending the request and the server keeps responding 200 Ok.
Here's the relevant part of my web config:
WebContentInterceptor webContentInterceptor = new WebContentInterceptor();
webContentInterceptor.setUseCacheControlHeader(true);
webContentInterceptor.setUseExpiresHeader(true);
webContentInterceptor.setUseCacheControlNoStore(true);
webContentInterceptor.setCacheSeconds(30);
registry.addInterceptor(webContentInterceptor);
And the cache control headers as per chrome:
Request URL:https://localhost:8443/admin/banners/json/by_shortcode/banner_test
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:sidebar_closed=1; SPRING_SECURITY_REMEMBER_ME_COOKIE=UmljaGFyZC5HaWxsaW5nQGdtYWlsLmNvbToxNDIzODgzOTI1MTY4OmU1OGM2YzVjNjIwMWIyNWM3OTZlMWM5MThjMDc0MDg4; JSESSIONID=70842F221D3172686E406242AD3F5E02
Host:localhost:8443
Referer:https://localhost:8443/admin/pages/new
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36
X-Requested-With:XMLHttpRequest
Response Headers
Cache-Control:max-age=30
Content-Type:application/json;charset=UTF-8
Date:Mon, 02 Feb 2015 14:03:13 GMT
Expires:Mon, 02 Feb 2015 14:03:43 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
Strict-Transport-Security:max-age=31536000 ; includeSubDomains
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:DENY
X-XSS-Protection:1; mode=block
What I'm wondering is:
a) Why is the browser re-requesting the same request within the 30 second window? I am hoping to cache it for 30seconds.
Actually you tell the browser not to cache anything: Pragma:no-cache.
I have a quick question but in advance I've read the RFC 2616 Chapter 14.22 about Host and HTTP Header but I still not understand where in httpd.conf or configuration file of a webserver should be changed? Please correct me if I'm wrong.
Look at following two HTTP GET I did to an Apache. The first one is GET for HTTP 1.0 , the other one is GET for HTTP 1.1. See the output:
HTTP/1.0 200 OK
Date: Thu, 24 Oct 2013 03:46:22 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Vary: *
Last-Modified: Fri, 10 Aug 2012 20:22:30 GMT
ETag: "17c815b-3b-50256d86"
Accept-Ranges: bytes
Content-Length: 59
Connection: close
Content-Type: text/html
<html>
<body>
<center>webli7</center>
</body>
</html>
HTTP/1.1 400 Bad Request
Date: Thu, 24 Oct 2013 04:04:40 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a PHP/5.2.9 mod_throttle/3.1.2 mod_psoft_traffic/0.2 mod_ssl/2.8.31 OpenSSL/0.9.8b
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
16e
The HTTP protocol version is decided dynamicaly, not through configuration files. The client send a request specifying the highest protocol version that its support. Then, the server must respond with either the version requested by the client, or any earlier version that it prefers.
Since Apache does support HTTP/1.1, it should therefore match exactly the version provided by the client.
There exist a flag that you may set in Apache's config to force Apache to use HTTP/1.0 in certain situations, even though the browser requested HTTP/1.1. This is used to fix bugs in HTTP/1.1 handling of some very old browser. Today, you should not need to play with this flag.
As for your error, I would suggest that you make sure that your GET does provide the Host: header. This header is required in HTTP/1.1, yet optional in HTTP/1.0, and having it missing would certainly result in a 400 error.
hen a server replies to a HTTP GET request why doesn't it specify in say some new header, the GET request for which this response was generated?
GET /counter.gif HTTP/1.1
Host: www.subbu.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP/1.1 200 OK
Date: Mon, 19 Dec 2011 00:12:28 GMT
Server: Apache
Last-Modified: Thu, 08 Dec 2011 15:29:54 GMT
Accept-Ranges: bytes
Content-Length: 24523
Content-Type: image/png
**Get-request: /counter.gif**
This will help in case the requests are pipelined. The server can send the replies in the order they are generated and the browser can interpret what the reply is for. I know HTTP is stateless but this seems like a simple optimization. Why do you think it might be a problem to implement this?
Like that:
https://datatracker.ietf.org/doc/html/draft-nottingham-http-pipeline-00#section-5
?
If your using apache you may be referring to this functionnality: Trace
When trace is set to extended, it reflect the request body.
Regards
I have a web application running on Glassfish. The application is written in Java using Servlets.
The application allows you to upload files and get a direct link to that file.
For some reason, Safari and Chrome (possibly other browsers) have issues playing MP3 files (and other audio/video files) uploaded to this application.
An example uploaded MP3: http://uploads.graalcenter.org/upload/test.mp3
Sometimes, Safari will load the file and play it correctly, but most of the time it either stays on "Loading..." forever, or starts playing for a few seconds and then stops downloading it.
My browser is sending these request headers:
GET http://uploads.graalcenter.org/upload/test.mp3 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7) AppleWebKit/535.1+ (KHTML, like Gecko) Version/5.1 Safari/534.48.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://uploads.graalcenter.org/info/test.mp3
Cache-Control: max-age=0
My server is responding with these response headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:02:03 GMT
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.2-b06 Java/Sun Microsystems Inc./1.6)
Content-Length: 1137602
Server: GlassFish Server Open Source Edition 3.2-b06
Content-Type: audio/mpeg
Accept-Ranges: none
For comparison, I have uploaded the same file to an Apache server here.
The server responds with these headers:
HTTP/1.1 200 OK
Date: Sun, 31 Jul 2011 02:06:56 GMT
Connection: Keep-Alive
Content-Length: 1137602
Last-Modified: Sun, 31 Jul 2011 02:05:57 GMT
Server: Apache
Etag: "1aa08001-115bc2-4a953f48b6b40"
Content-Type: audio/mpeg
Accept-Ranges: bytes
Keep-Alive: timeout=2, max=100
The file plays correctly.
The only difference I can see is that my application does not accept range requests, but this shouldn't cause any issues, should it?
If I download the MP3 from my web application via curl, it has the same MD5 hash, so it's not corrupting the MP3 in any way.
Does anybody have any idea what might be causing the MP3 to not play correctly?
It seems like the problem was AppleCoreMedia, the plugin which handles audio, doesn't work correctly when not using range data. I wouldn't make the leap of blaming it on Apple, as it's entirely possible I made some mistake, but I ended up implementing the HTTP Range header and the it now works every time.