Well I have a weired issue, I was trying fronting tomcat with apache mod_jk using worker.
If I update my form with something like http://server.internal:8080 i.e tomcat then it works fine i.e updates are shown on screen and onrefresh the updates retain.
But if I update form with apache i.e http://server.internal/ then updates are seen in database but on refresh UI shows old values only, after refreshing 5-10 times then UI shows new values.
Also during refresh sometimes it shows old values while sometimes new values in the form.
I am using tomcat 7 + apache 2.2 + mod_jk on windows server.
I have disabled caching modules but still getting error.
Not sure where and how to debug such an issue.
Edited ---------
Request headers with apache
Cache-Control no-cache,no-store,private,pre-check=0,post-check=0,max-age=0
Connection close
Content-Encoding gzip
Content-Length 10174
Content-Type text/html;charset=utf-8
Date Thu, 11 Dec 2014 19:39:36 GMT
Expires -1
Pragma no-cache
Server Apache/2.2.25 (Win32) mod_jk/1.2.40
Vary Accept-Encoding
Request headers with tomcat
Content-Type text/html;charset=utf-8
Date Thu, 11 Dec 2014 19:43:43 GMT
Server Apache-Coyote/1.1
Transfer-Encoding chunked
Response Header with apache
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control max-age=0
Connection keep-alive
Cookie JSESSIONID=7D3ACA49B478E8B3A126B37252B62481
Host server
User-Agent Mozilla/5.0 (Windows NT 6.0; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Response header with tomcat
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Cookie JSESSIONID=7D3ACA49B478E8B3A126B37252B62481
Host server:8080
User-Agent Mozilla/5.0 (Windows NT 6.0; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Does not look a caching issue, tried with KeepAlive off also
I think its problem with the browser local history, delete the history in your browser and try again.mostly it will works fine.
This definitely smells like a caching issue. To be sure, explicitly purge your browser's cache (or disable it) and see if that helps. If it does, you may
want to add this in your apache's httpd.conf (replace the pattern */yourform.jsp by something that matches your form page(s)) in order to mark these pages as "uncacheable":
<Proxy */yourform.jsp>
Header unset Pragma
Header Always set Cache-Control: "no-cache,no-store,private,pre-check=0,post-check=0,max-age=0"
Header Always set Pragma: "no-cache"
Header Always set Expires "-1"
</Proxy>
Related
General:
Request URL:x/site.php
Request Method:OPTIONS
Status Code:302 Found
Remote Address:x.x.x.x:80
Response Headers:
view source
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Origin:*
Access-Control-Max-Age:300
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Length:0
Content-Type:text/html; charset=UTF-8
Date:Thu, 02 Mar 2017 14:27:21 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Location:y
Pragma:no-cache
Server:Apache/2.4.25 (Ubuntu)
Request Headers:
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:authorization
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:x
Origin:http://127.0.0.1:3000
Pragma:no-cache
Referer:http://127.0.0.1:3000/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36
Apache virtualhost config looks as so:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://127.0.0.1:3000"
Header set Access-Control-Allow-Origin "http://127.0.0.1"
Header set Access-Control-Max-Age "300"
Header set Access-Control-Allow-Credentials "true"
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"
Header set Access-Control-Allow-Methods "POST, GET, PUT, DELETE, PATCH, OPTIONS"
</IfModule>
The preflight request is skipping the apache config and hitting my webapp directly, which does a redirect (hence the 302 and the location: y).
I don't know why the preflight request is not being handled by apache?
To fully CORS-enable an Apache web server, you need to have it configured to look like this:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Headers "Authorization"
Header always set Access-Control-Allow-Methods "GET"
Header always set Access-Control-Expose-Headers "Content-Security-Policy, Location"
Header always set Access-Control-Max-Age "600"
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Longer explanation at https://benjaminhorn.io/code/setting-cors-cross-origin-resource-sharing-on-apache-with-correct-response-headers-allowing-everything-through/
Some general notes on what values to set for the various Access-Control- response headers:
Access-Control-Allow-Headers: you must set it to include any header names your request sends except CORS-safelisted header names or so-called “forbidden” header names (names of headers set by the browser that you can’t set in your JavaScript); the spec alternatively allows the * wildcard as its value—so you can try it, though some browsers may not support it yet: Chrome bug, Firefox bug, Safari bug.
Access-Control-Allow-Methods: the spec alternatively allows the * wildcard—but again, as with Access-Control-Allow-Headers: *, some browsers may not support it yet.
Access-Control-Expose-Headers: set to include any response headers beyond Expires, Cache-Control, Content-Type, Pragma, Last-Modified, and Content-Language that your frontend code needs to read. A lot of people forget to set this and end up baffled about why they can’t read the value of a particular response header). Again the spec alternatively allows the * wildcard here, but some browsers may not support it yet.
Access-Control-Max-Age: Chrome has an upper limit of 600 (10 minutes) hardcoded, so there’s no point in setting a higher value for it than that (Chrome will just throttle it down to 10 minutes if you set it higher, and Safari limits it to only 5 minutes).
So then, about the particular request shown in the question, the specific changes and additions that would need to made are these:
Use Header always set instead of just Header set.
Use mod_rewrite to handle the OPTIONS by just sending back 200 OK with those headers.
The request has Access-Control-Request-Headers:authorization so in the Apache config, add Authorization in the Access-Control-Allow-Headers response header too.
Origin is a “forbidden” header name set by the browser, and Accept is a CORS-safelisted header name, so no need to include them in Access-Control-Allow-Headers.
The request sends no Content-Type, so no need for it in Access-Control-Allow-Headers in the response (and never needed for GET requests and otherwise only needed if the type is not application/x-www-form-urlencoded, text/plain, or multipart/form-data).
For Access-Control-Allow-Methods, the request seems to just be a GET, so unless the plan’s to also make POST/PUT/DELETE/PATCH requests, no point in including them.
Given these request headers:
Host: api.example.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.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
DNT: 1
Origin: https://web.example.org
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
And these response headers:
Connection: keep-alive
Content-Length: 0
Content-Type: text/plain; charset=utf-8
Date: Tue, 13 Oct 2015 10:57:34 GMT
Server: nginx/1.8.0
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: PUT, DELETE, PATCH
access-control-allow-origin: *
This works even though only the Authorization and Content-Type headers are explicitly allowed. Why didn't I have to allow other headers that my browser sends? (like DNT for example)
Update: this MDN page contains an overview of simple headers (default CORS-safelisted request headers):
A simple header (or CORS-safelisted request header) is one of the
following HTTP headers:
Accept
Accept-Language
Content-Language
Content-Type with a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded, multipart/form-data, or text/plain.
Or one of these client hint headers:
DPR
Downlink
Save-Data
Viewport-Width
Width
Without seeing your code to generate the headers, or on which system you are serving from, i.e. nginx or apache, the best I can do is refer you to http://client.cors-api.appspot.com/client which will allow you to test your CORS requests. Also, you should look at http://enable-cors.org/server.html for your specific setup. For instance on nginx, you could have something like this
add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
There is a set of normal headers, and then the set of headers that you have to explicitly call out. see http://www.html5rocks.com/en/tutorials/cors/#toc-adding-cors-support-to-the-server about setting it up on a server.
The Access-Control-Allow-Headers is attached by backend, you cannot control that header on client side.Access-Control-Allow-Headers should be returned in response object.
So to include other headers into Access-Control-Allow-Headers header in response object - you have to configure your web server or update backend application which serves requests to attach desired value of Access-Control-Allow-Headers to each request.
To allow any headers in your client requests server should add Access-Control-Allow-Origin: * header to each response.
There are a lot of articles and info of how you can setup CORS to work in the way you want. For example that one - Enabling CORS
I'm using LAMP (Linux, Apache, MySQL, PHP) server.
Currently the server sends the response with next Headers list. I want to eliminate Keep-Alive entry for security reasons, to have Headers list without it. Is it possible to prevent sending the Keep-Alive entry in the Headers list?
Current Response Headers:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Keep-Alive timeout=5, max=200
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Response Headers I Would Like Instead:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Is it possible to prevent sending the Keep-Alive entry in the Headers list?
To my knowledge, no. The whole purpose of the Keep-Alive header is to communicate the need for a persistent connection to the client. So getting rid of the headers gets rid of the main form of communication between the client & the server.
That said, you might be able to get it unset by using unset in your Apache config or .htaccess as explained here. I emphasize might since I have had header directives not behave as expected in some versions of Apache. But assuming good faith, first be sure the headers module is enabled. In Ubuntu 12.04 you would do this:
sudo a2enmod headers
And then add this to your Apache config or .htaccess:
<IfModule mod_headers.c>
Header unset Keep-Alive
</IfModule>
Now restart Apache:
sudo service apache2 restart
More details on the header directive are here.
There are a few ways to this in apache:
Server-wide using the KeepAlive directive ( KeepAlive ). However you can not have this in per-directory configuration files, so setting KeepAlive Off will turn off keep alive for the entire server.
Using SetEnv or SetEnvIf with mod_env, and set the nokeepalive environmental variable. This will turn off keepalive for the location where the environmental is set, or the rule that is matched by SetEnvIf (depending with you use). e.g.
can be in HTACCESS
SetEnv nokeepalive 1
Using mod_rewrite to again set the environmental for a specific rule, e.g.
RewriteRule some-file.html - [E=nokeepalive:1]
Using PHP (or any other server site language) and sending the header Connection: close. This will cause Apache to omit the Keep-Alive header, since the connection is no longer keepalive. e.g.
php
header('Connection: close');
Use mod_headers to set the connection header to close again, e.g.
Header set Connection "close"
I personally have not tested the last one, but it should work.
KeepAlive behavior (availability and timeouts) is directly configurable:
http://httpd.apache.org/docs/2.4/mod/core.html#keepalive
Changing this is primarily an aspect of performance rather than security, but you're free to test the implications in your own environment.
We have an odd, intermittent error that occurs with mod_proxy_ajp, i.e. using apache as a front end to a tomcat server.
The error
User clicks on a link browser prompts
user to "save as...." (e.g. in
Firefox "You have chosen top open
thread.jsp which is a
application/octet-stream"...What
should firefox do with this file)
User says "Huh?" and presses "Cancel"
User clicks again on the same link
Browser displays the page correctly
This error occurs intermittently, but unfortunately rarely on our test server and frequently on production.
In firefox's LiveHttpHeaders I see the following in the above usecase:
first page download (i.e. click on link) is "text/plain"
second download is "text/html"
I thought the problem may stem from ProxyPassReverse (i.e. muddling up whether to use http or ajp), but all these proxypassreverse settings resulted in the same error:
ProxyPassReverse /ajp://localhost:8080/
ProxyPassReverse /pe http://localhost/pe
ProxyPassReverse /pe http://forumstest.company.com/pe
Additionally, I've checked the apache error logs (set to debug) and see no warnings or errors...
** But it works with mod_proxy_http ?? **
It appears that switching to mod_proxy_http 'solves' the problem. Limited testing, I have not been able to recreate the problem in the test environment.
Because the problem is intermittent, I'm not 100% sure that mod_proxy_http "solves" the problem
Environment
Apache 2.2 Windows
Jboss 4.2.2 back end (tomcat 6)
One other data point
For better or worse, a servlet filter in tomcat gzips the html before sending it to apache. (which means extra work as apache must unzip before it performs ProxyPassReverse's "find and replace"). I don't know if "gzip" messes up.
Questions
anyone seen this before?
what tools help analyze the cause?
thanks
Addendum 1: Here is the LiveHttpHeaders output
Browser Incorrectly sees html as "text/plain"
http://forums.customer.com/pe/action/forums/displaythread?rootPostID=10842016&channelID=1&portalPageId=1002
GET http://forums.customer.com/pe/action/forums/displaythread?rootPostID=10842016&channelID=1&portalPageId=1002 HTTP/1.1
Host: forums.customer.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729)
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: 115
Proxy-Connection: keep-alive
Cookie: __utma=156962862.829309431.1260304144.1297956514.1297958674.234; __utmz=156962862.1296760237.232.50.utmcsr=forumstest.customer.com|utmccn=(referral)|utmcmd=referral|utmcct=/pe/action/forums/displaythread; s_vi=[CS]v1|258F5B88051D3FC3-40000105C056085F[CE]; inqVital=xd|0^sesMgr|{"sID":4,"lsts":1292598007}^incMgr|{"id":"755563420055418864","group":"CHAT","ltt":1292598006741,"sid":"755563549194447187","igds":"1290627502757","exempt":false}^inq|{"customerID":"755562378269271622"}^saleMgr|{"state":"UNSOLD","qDat":{},"sDat":{}}; inqState=sLnd|1^Lnd|{"c":4,"flt":1274728016,"lldt":17869990,"pgs":{"201198":{"c":1,"flt":1274728016,"lldt":0},"0":{"c":3,"flt":1274845009,"lldt":17752997}},"pq":["0","0","0","201198"],"fsld":1274728016697}; adv_search_results_page=10; ep_beta=1; visitorID=57307059; JSESSIONID=6jXLNdHRDjR9Th3B5gvTVkw1dZLn1zvhvKLR2r4GTLjylHJgjY3Q!683274050; __utmc=156962862; JSESSIONID=6jXLNdHRDjR9Th3B5gvTVkw1dZLn1zvhvKLR2r4GTLjylHJgjY3Q!683274050; TLTHID=5CCA50304DE99E28DB79A7B3267D4231; TLTSID=9DFCDE8045B374AAB752CC98A30E8311; AreCookiesEnabled=1; s_cc=true; SC_LINKS=%5B%5BB%5D%5D; s_sq=%5B%5BB%5D%5D; __utmb=156962862.64.10.1297958674; memberexists=T; ev1=greywolf%20hdtv%20whmx
Cache-Control: max-age=0
HTTP/1.0 200 OK
Date: Thu, 17 Feb 2011 17:38:42 GMT
Content-Type: text/plain
X-Cache: MISS from samus.company.com
X-Cache-Lookup: MISS from samus.company.com:3128
Via: 1.0 samus.company.com:3128 (squid/2.6.STABLE20)
Proxy-Connection: close
----------------------------------------------------------
Browser Correctly sees html as "text/html"
http://forums.customer.com/pe/action/forums/displaythread?rootPostID=10842016&channelID=1&portalPageId=1002
GET http://forums.customer.com/pe/action/forums/displaythread?rootPostID=10842016&channelID=1&portalPageId=1002 HTTP/1.1
Host: forums.customer.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729)
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: 115
Proxy-Connection: keep-alive
Cookie: __utma=156962862.829309431.1260304144.1297956514.1297958674.234; __utmz=156962862.1296760237.232.50.utmcsr=forumstest.customer.com|utmccn=(referral)|utmcmd=referral|utmcct=/pe/action/forums/displaythread; s_vi=[CS]v1|258F5B88051D3FC3-40000105C056085F[CE]; inqVital=xd|0^sesMgr|{"sID":4,"lsts":1292598007}^incMgr|{"id":"755563420055418864","group":"CHAT","ltt":1292598006741,"sid":"755563549194447187","igds":"1290627502757","exempt":false}^inq|{"customerID":"755562378269271622"}^saleMgr|{"state":"UNSOLD","qDat":{},"sDat":{}}; inqState=sLnd|1^Lnd|{"c":4,"flt":1274728016,"lldt":17869990,"pgs":{"201198":{"c":1,"flt":1274728016,"lldt":0},"0":{"c":3,"flt":1274845009,"lldt":17752997}},"pq":["0","0","0","201198"],"fsld":1274728016697}; adv_search_results_page=10; ep_beta=1; visitorID=57307059; JSESSIONID=6jXLNdHRDjR9Th3B5gvTVkw1dZLn1zvhvKLR2r4GTLjylHJgjY3Q!683274050; __utmc=156962862; JSESSIONID=6jXLNdHRDjR9Th3B5gvTVkw1dZLn1zvhvKLR2r4GTLjylHJgjY3Q!683274050; TLTHID=5CCA50304DE99E28DB79A7B3267D4231; TLTSID=9DFCDE8045B374AAB752CC98A30E8311; AreCookiesEnabled=1; s_cc=true; SC_LINKS=%5B%5BB%5D%5D; s_sq=%5B%5BB%5D%5D; __utmb=156962862.64.10.1297958674; memberexists=T; ev1=greywolf%20hdtv%20whmx
Cache-Control: max-age=0
HTTP/1.0 200 OK
Date: Thu, 17 Feb 2011 17:38:44 GMT
X-Powered-By: Servlet 2.4; JBoss-4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)/Tomcat-5.5
Content-Encoding: gzip
Content-Type: text/html;charset=UTF-8
Content-Length: 24739
X-Cache: MISS from samus.company.com
X-Cache-Lookup: MISS from samus.company.com:3128
Via: 1.0 samus.company.com:3128 (squid/2.6.STABLE20)
Proxy-Connection: keep-alive
----------------------------------------------------------
Addendum 2: Additional Information
The browser did receive the "gzipped" file. I had earlier clicked "save as..." when a few of these errors occurred. Gunzip successfully processed the files and converted them to html.
Answer is here: How to preserve the Content-Type header of a Tomcat HTTP response sent through an AJP connector to Apache using mod_proxy
set DefaultType to None in apache configuration.
# DefaultType: the default MIME type the server will use for a document
# if it cannot otherwise determine one, such as from filename extensions.
# If your server contains mostly text or HTML documents, "text/plain" is
# a good value. If most of your content is binary, such as applications
# or images, you may want to use "application/octet-stream" instead to
# keep browsers from trying to display binary files as though they are
# text.
#
DefaultType None
The first page download is of mime type "application/octet-stream". May be the zipped stream is being sent back to the browser? (You can confirm by saving the file and looking inside it.)
It would be really helpful to post the Live HTTP Header request / response traces for problematic and normal cases. If the content is same in both cases - the response HTML - may be forcing the mime type to be text/html (using ForceType directive) for that particular context can fix the issue.
If it turns out to be the case that gzipped content is being sent to the browser in the problematic case - then digging deeper would be necessary. Is this browser specific - only happens with Firefox or happens with all browsers?
Ok, based on the new information provided - looks like Squid is caching the problematic response and not sending the right headers back to the client. So the browsers are doing the right thing here - without the Content-Encoding and right Content-Type they cannot do much else.
Missing response headers for the problematic request :
X-Powered-By: Servlet 2.4; JBoss-4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)/Tomcat-5.5
Content-Encoding: gzip
Content-Type: text/html;charset=UTF-8
X-Powered-By : It sounds like the problematic requests don't actually hit your JBoss server. Can you verify this by checking access logs? Is Squid caching the response and then sending it back as text/plain?
Reconfiguring Squid to not cache that particular URL should help - see http://www.lirmm.fr/doc/Doc/FAQ/FAQ-7.html section 7.8 for example (which is specific to Squid 2 but later versions should have similar capabilities.)
Seems like a content-negotiation problem. Apache is guessing the content type using the "magic" byte and setting the content type incorrectly. That explains why it happens intermittently. Try disabling mod_negotiation and see what happens. See http://httpd.apache.org/docs/2.0/content-negotiation.html for more info.
I saw the following in your settings
ProxyPassReverse /ajp://localhost:8080/
But port 8080 is not ajp port. The default ajp port is 8009. Could this be your problem?
There is most likely something wrong with your web application, not Apache. If your web app sends back the correct Content-Type, Apache will gladly forward it to the client. No content negotiation will be done in that case. If you do not return any Content-Type, Apache will almost surely substitute text/plain, which is not what you want.
Test your web app without Apache in the middle, make sure that it sends back the correct Content-Type.
It uses to be when apache serves secure content in a non secure channel.
I am having an issue with the browser not caching a SWF file.
I have the following in my apache configuration:
ExpiresByType application/x-shockwave-flash "access plus 2 months"
I can see the headers coming back from the original request for the SWF look like this (the expires header looks like it's being set properly):
Request:
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Accept HTTP Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip,deflate
Cookie auth_token=
Response:
Server Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.5 with Suhosin-Patch proxy_html/3.0.0 mod_ssl/2.2.8 OpenSSL/0.9.8g Phusion_Passenger/2.2.5
Last-Modified Sat, 14 Nov 2009 04:48:19 GMT
Etag "49384-4784d7c3c8ac0"
Accept-Ranges bytes
Content-Length 299908
Cache-Control max-age=5184000
Expires Fri, 15 Jan 2010 20:25:42 GMT
Content-Type application/x-shockwave-flash
However, on subsequent loads of the page, the browser still sends If-Range requests for the SWF as follows:
Request:
User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Accept HTTP Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip,deflate
Cookie auth_token=
Range bytes=0-
If-Range "49384-4784d7c3c8ac0"
Response:
Server Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.5 with Suhosin-Patch proxy_html/3.0.0 mod_ssl/2.2.8 OpenSSL/0.9.8g Phusion_Passenger/2.2.5
Last-Modified Sat, 14 Nov 2009 04:48:19 GMT
Etag "49384-4784d7c3c8ac0"
Accept-Ranges bytes
Content-Length 299908
Cache-Control max-age=5184000
Expires Fri, 15 Jan 2010 20:25:45 GMT
Content-Range bytes 0-299907/299908
Content-Type application/x-shockwave-flash
These subsequent requests appear to be sending the Etag in the If-Range header, and are getting 206 responses with the entire content. I've tried setting apache up to unset the Accept-Ranges header and Etags, but the browser will re-request the file in either cases.
Has anyone seen anything like this before and know what to do to get the SWF to cache?
Thanks!