Chrome 39 cannot reload PDF served via range request
Description
Attachments
is related to
relates to
Activity
Hudson CI Server December 16, 2014 at 8:16 PM
SUCCESS: Integrated in sakai-10-java-1.7 #155 (See http://builds.sakaiproject.org:8080/job/sakai-10-java-1.7/155/)
Merge 316006 from trunk (matthew@longsight.com: rev 316064)
Juan Arcadio Martinez Carceles December 16, 2014 at 2:47 AM
Tested on http://nightly2.sakaiproject.org:8081/ at revision 316066.
The PDF requested does a multipart response.
Neal Caidin December 15, 2014 at 7:48 PMEdited
For the test plan, do I just need to ensure that I can open a PDF within a Chrome Browser window or tab?
Wanting to test on 10.x.
Matthew Jones December 15, 2014 at 7:39 PM
Since Sam tested it to not change any current behavior and this is just a temporary fix, I'm just going to merge as is. There's already a few other schools that have merged it. I think the risk of putting in mime types and missing some might be more of a risk.
Sam Ottenhoff December 12, 2014 at 11:15 AM
I've tested current behavior by modifying a simple text file on https://qa10.longsight.com/access/content/public/ and have confirmed no major browser (IE, FF, Chrome) currently caches the file. My conclusion is that we don't need to worry about regressing any existing caching.
I believe we should merge and then remove this Cache-Control header once we have Last-Modified or ETag added in KNL-1315.
Reported on DEV list by Matthew Buckett. Also reported as a Chromium bug:
https://code.google.com/p/chromium/issues/detail?id=437738
And another source at
https://code.google.com/p/chromium/issues/detail?id=437648
This feature was originally contributed on https://jira.sakaiproject.org/browse/KNL-215 and it says it pulls out of DefaultServlet.java.
Looking at a more current source of this at
http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java