I tried googling this by hard but was unsuccessful so far.
I've got an apache 2.2.16 on Debian with mod_deflate loaded and enabled like this:
LoadModule deflate_module /usr/lib/apache2/modules/mod_deflate.so
and
AddOutputFilterByType DEFLATE text/html text/css text/javascript application/x-javascript
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%) "%{User-agent}i"' deflate
CustomLog /var/log/apache2/deflate_log deflate env=!trash
When I open a page the log file says that it's compressing my CSS file (and others):
"GET / HTTP/1.1" -/- (-%) "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17"
"GET /www/js/dojoToolkit/dijit/themes/claro/claro.css HTTP/1.1" 17244/118618 (14%) "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17"
"GET /www/css/basis-min.css HTTP/1.1" 10877/61154 (17%) "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17"
But Firebug and also Chrome do still get the uncompressed files, although the explicitly accept gzip and deflate encoding.
One interesting fact is also that the
Vary: Accept-Encoding
header is still set, unlike the Content-Encoding:
GET /www/js/dojoToolkit/dijit/themes/claro/claro.css HTTP/1.1
Host: www.getabstract.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,de-ch;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.getabstract.com/
Cookie: __utma=73758084.1377620539.1310985055.1310989511.1310990668.3; __utmz=73758084.1310985055.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); fpc10001731534234=Y63gTWM9|aCXc2doLaa|fses10001731534234=|aCXc2doLaa|Y63gTWM9|fvis10001731534234=Zj1odHRwJTNBJTJGJTJGd3d3LmdldGFic3RyYWN0LmNvbSUyRiZiPUhvbWVwYWdlJTIwRU4=|8M8Y7oT7YH|8M8Y7oT7YH|8M8Y7oT7YH|8|8M8Y7oT7YH|8M8Y7oT7YH; __ar_v4=262MD4C3UNHKBELB3VUEGS%3A20110717%3A20%7CTBE3U4YYEBCGHJ2QAUBVE4%3A20110717%3A20%7CXVIJYAN7KFDQXPECC3AI7E%3A20110717%3A20; JSESSIONID=abcKrMR5EVQv68Os6h9et; __utmc=73758084
Pragma: no-cache
Cache-Control: no-cache
Response:
HTTP/1.1 200 OK
Date: Mon, 18 Jul 2011 13:54:45 GMT
Server: Apache
Last-Modified: Wed, 04 May 2011 10:49:12 GMT
Etag: "28023a-1cf5a-4a27101cc1a00"
Accept-Ranges: none
Cache-Control: max-age=600
Expires: Mon, 18 Jul 2011 14:04:45 GMT
Vary: Accept-Encoding
Content-Length: 118618
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/css
Any ideas?
Thanks in advance.
Marc
Long shot: is apache treating your css file correctly - i.e. are the mime types configured correctly?
Where is your output filter set, in an included config or in an .htaccess [check that .htaccess is allowed to override]
Can you remove the filter & see if it will compress all content?
Lastly - is there a public URL we can test?
-sean
EDIT:
Hi Again, what are you using to test locally? I can see the correct content encoding in firefox/firebug/yslow. - [I also see several other issues] - if you are not using firebug, I suggest checking it out [strongly!] - but otherwise, yes, it appears your compression is working correctly.
-sean
Related
I've read that Chrome keeps asking for the favicon in each page it visits (link), and if it doesn't find it (404 Not found) then Chrome enters in a infinite loop.
I'm afraid that is happening to my app, although it works fine with Firefox or Safari. I haven't found a way to prevent this after go through all the forums I could find.
The http headers before the problematic request is:
GET /url?file_id=0B0orkZUr6JxAdmViVmNuTG5XbFU HTTP/1.1
Host: glinksapp.appspot.com:443
Accept: image/webp,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nW31wx9PEvsqASLQKFZts0Ux1pWFwk...[cut]
Referer: https://www.google.es/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
X-Purpose: Instant
HTTP/1.1 302 Found
content-length: 0
content-type: text/html
date: Sun, 14 Jul 2013 08:59:56 GMT
location: https://drive.google.com/#folders/0B0orkZUr6JxAVk9xT3QxcXBpdWs
server: Google Frontend
status: 302 Found
version: HTTP/1.1
And this is the infinite loop in Chrome:
GET /favicon.ico HTTP/1.1
Host: drive.google.com:443
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: NID=67=fwmd6KsM_Y0xNrRMQlSSpVVmsKTgAi8v4AlG9A...[cut]
PREF=ID=ad9194453b59885b:FF=0:LD=en:TM=1373791886:LM=1373792185...[cut]
SID=DQAAAHABAACKf5HqkBRzvi3HwJrZJ1nWZBxbrbYxeGjE4p130PeYTaQhalIhrt6T-...[cut]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Chrome-Variations: COS1yQEIl7bJAQiptskBCMG2yQEIm4TKAQj4hMoBCLeFygEIwoXKAQjRhcoB
HTTP/1.1 404 Not Found
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-encoding: gzip
content-length: 117
content-type: text/html; charset=UTF-8
date: Sun, 14 Jul 2013 08:59:56 GMT
expires: Fri, 01 Jan 1990 00:00:00 GMT
pragma: no-cache
server: GSE
status: 404 Not Found
version: HTTP/1.1
x-chromium-appcache-fallback-override: disallow-fallback
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
If you refresh the page, the app comes out from the loop.
My Java app's url is http://glinksapp.appspot.com and is hosted in Google App Engine. It is a drive app to open link files (webloc, url...) directly in Google Drive (something not provided by Google by default).
The question is: how to avoid entering in the 404 'Not found' loop when the app tries to reach 'drive.google.com/favicon.ico'?
Thx in advance.
Chrome and other browsers automatically request the favicon, but they don't enter an infinite loop when they get a 404 (which happens on a lot of sites, so that would be a gigantic problem). The link you posted says that Chrome on Android may request the apple-touch-icon files as well, but that's okay.
The HTTP 404 response you've pasted into your question looks totally fine. Your 302 redirect also looks fine. So I suspect the problem you're experiencing is something else, not related to the favicon.
I'm using blobstore to serve audio files embedded in HTML5 audio element. Because I have a blobkey as a part of url I can assume that for any given url its content will never change. That looks like a perfect setup for caching.
Yesterday I implemented a solution which seemed to work. At least I remember that it worked ;). Unfortunately today I discovered, that it doesn't work with Chrome and production server. It works perfectly with Internet Explorer and Firefox. It even works with Chrome and development server - I use version 1.7.6. My solution uses Cache-Control headers, but it seems that only Firefox makes any use of it. Additionally I added an ETag header. When I discover If-None-Match request header with the same value I return 304 code. That seems to work with Internet Explorer. It also works with Chrome and development server. I remember that it had worked yesterday with Chrome and production, but I'm not completely sure. Anyway the problem I have is why both caching mechanisms are ignored by Chrome. I suspect that it may have something to do with chunked encoding which is generated only for chrome, but I don't understand why caching is disabled in that case
And now a lot of details.
Firefox
Initial request headers:
Host: eduzabawy.appspot.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5
Accept-Language: pl,en-us;q=0.7,en;q=0.3
Range: bytes=0-
Referer: http://eduzabawy.appspot.com/dziecko/
Cookie: children="jEDor1B8VRDRJreWmUVlUQ\075\075"; session=eyJfc2lkIjoiWk91QmlsOEJlTEd4QVFuYVFiYkpsTyJ9|1365190508|81d81772f6f409dd57ad43a9f447f92d1b56d29e
Connection: keep-alive
Initial response headers:
HTTP/1.1 206 Partial Content
Cache-Control: public max-age=100000000
Content-Range: bytes 0-37249/37250
Content-Type: audio/ogg
Date: Fri, 05 Apr 2013 19:45:47 GMT
Etag: blobstore
Server: Google Frontend
X-Firefox-Spdy: 3
On subsequent loads it seems that Firefox doesn't even try to fetch the files. This is how I thought it should work.
Internet Explorer
Initial request headers:
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Host: eduzabawy.appspot.com
Connection: Keep-Alive
Cookie: children="WyzUQwHEzwX6qnjfn21KEw\075\075"; session=eyJfc2lkIjoia2VOd0llR0hvRHU1cUN0cE1QSWRpWCJ9|1365192921|f2279f82b21947c4d064dbf44a5ce9e1bd95cc0d
Initial response headers:
HTTP/1.1 200 OK
Cache-Control: public max-age=100000000
ETag: blobstore
Content-Type: audio/mpeg
Date: Fri, 05 Apr 2013 20:15:23 GMT
Server: Google Frontend
Content-Length: 4637
Subsequent request headers:
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Host: eduzabawy.appspot.com
If-None-Match: blobstore
Connection: Keep-Alive
Cookie: children="WyzUQwHEzwX6qnjfn21KEw\075\075"; session=eyJfc2lkIjoia2VOd0llR0hvRHU1cUN0cE1QSWRpWCJ9|1365192921|f2279f82b21947c4d064dbf44a5ce9e1bd95cc0d
Subsequent response headers:
HTTP/1.1 304 Not Modified
ETag: blobstore
Content-Type: audio/mpeg
Content-Length: 4637
Chrome + development server
Initial request headers:
Host: localhost:8080
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://localhost:8080/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="xYNsqzfdtZ-2Z764lFSzk1Ed8-g1QoNlcaexsD79gSY\075"; session=eyJfc2lkIjoiTE9CZDc0SHJENHF4OWJua1J4S3dTQSJ9|1365192253|37815772acab0bf44a0c501ea0fd0dc7c617dd09
Range: bytes=0-
Initial response headers:
HTTP/1.1 206 Partial Content
etag: blobstore
cache-control: public max-age=100000000
content-type: audio/mpeg
Content-Range: bytes 0-4636/4637
Content-Length: 4637
Server: Development/2.0
Date: Fri, 05 Apr 2013 20:32:19 GMT
Subsequent request headers:
Host: localhost:8080
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://localhost:8080/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="xYNsqzfdtZ-2Z764lFSzk1Ed8-g1QoNlcaexsD79gSY\075"; session=eyJfc2lkIjoiTE9CZDc0SHJENHF4OWJua1J4S3dTQSJ9|1365192253|37815772acab0bf44a0c501ea0fd0dc7c617dd09
Range: bytes=0-4636
If-None-Match: blobstore
Subsequent response headers:
HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: Development/2.0
Date: Fri, 05 Apr 2013 20:33:08 GMT
Chrome + production server
Initial request headers:
Host: eduzabawy.appspot.com
Connection: keep-alive
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31
Accept: */*
Referer: http://eduzabawy.appspot.com/dziecko/
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: children="sU9aqnqEf67eZFpS7BKSMw\075\075"; session=eyJfc2lkIjoieFlGWlJLMnRwSHJuOVFCb1haTnJLUCJ9|1365194193|2a13cd9eb7aceeb40c43bd82a763d893436d9f1f
Range: bytes=0-
Initial response headers:
HTTP/1.1 206 Partial Content
Cache-Control: public max-age=100000000
ETag: blobstore
Content-Type: audio/mpeg
Content-Range: bytes 0-4636/4637
Date: Fri, 05 Apr 2013 20:36:35 GMT
Server: Google Frontend
Transfer-Encoding: chunked
Subsequent requests and responses are the same as initial.
Your max-age seems too long and going over 3 years... I read from somewhere the maximum you should set in GAE is no more than 1 year.
Anyway, there's one more header you should try to set (Pragma: Public), which worked for me (I'm caching image from blobstore though, here's a few lines from my source code):
httpResponse.Header().Set("Cache-Control", "public, max-age=600")
httpResponse.Header().Set("Pragma", "Public")
blobstore.Send(httpResponse, project.ImageBlobKey)
By the way the above also cause Google to delivery your file from the edge cache, which really speed static resources up a lot!
I am debugging js code on localhost and I need to prevent the caching of files by the browser. I can't use a timestamp appended to the url because it erases chrome debugger breakpoints.
Usually I don't have to refresh the cache, but everyone in a while I do. It is a large problem because I go searching elsewhere for the bugs. I added this code to apache some time ago:
<IfModule mod_headers.c>
Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
</IfModule>
Can someone explain why Apache would mistake a file for valid or provide some additions to the configuration code that could fix this once and for all?
Headers using the solution below:
<IfModule mod_expires.c>
expiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType text/javascript "access plus 1 seconds"
ExpiresByType application/x-javascript "access plus 1 seconds"
</IfModule>
http://localhost/static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png
GET /static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.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
Connection: keep-alive
Referer: http://localhost/static/images/
Cache-Control: max-age=0
HTTP/1.1 200 OK
Date: Sun, 23 Dec 2012 19:33:20 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Thu, 28 Jun 2012 17:32:51 GMT
Etag: "b3c27-f1f-4c38bb88d96c0"
Accept-Ranges: bytes
Content-Length: 3871
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: image/png
HTTP/1.1 200 OK
Date: Sun, 23 Dec 2012 19:33:54 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Thu, 28 Jun 2012 17:32:51 GMT
Etag: "b3c27-f1f-4c38bb88d96c0"
Accept-Ranges: bytes
Content-Length: 3871
Cache-Control: max-age=1
Expires: Sun, 23 Dec 2012 19:33:55 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/png
The second request:
http://localhost/static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png
GET /static/images/%d0%9a%d0%be%d0%bf%d0%b8%d1%8f%20logo_inner.png HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.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
Connection: keep-alive
Referer: http://localhost/static/images/
If-Modified-Since: Thu, 28 Jun 2012 17:32:51 GMT
If-None-Match: "b3c27-f1f-4c38bb88d96c0"
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Sun, 23 Dec 2012 19:34:58 GMT
Server: Apache/2.2.22 (Ubuntu)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=99
Etag: "b3c27-f1f-4c38bb88d96c0"
Expires: Sun, 23 Dec 2012 19:34:59 GMT
Cache-Control: max-age=1
When delivering static files, Apache sends an ETag header, which is something like a checksum of the file. The browser will cache the file and remember the ETag, which is sent with the next request.
If the file changes the browser ETag should differ and the webserver should resend, when the etag is equal, the webserver will respond with 304 Not Modified. The ETag mechanism has a higher priority than other cache headers.
To disable etags you can use apaches
FileETag None
http://httpd.apache.org/docs/current/en/mod/core.html#fileetag
Wikipedia has a nice article about the Etag header
http://en.wikipedia.org/wiki/HTTP_ETag
Edit
This should be a waterproof configuration
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>
Don't forget that configuration changes require a server restart to take effect.
sudo /etc/init.d/httpd restart
EDIT2
Wrap filesMatch around the configuration to disable caching for specific file extensions only
<filesMatch ".(php|js|css)$">
FileETag None
[..]
</filesMatch>
If i understand your requirement correctly you want the web browser to not remember anything about the webpage you are accessing and your apache web server should treat it like a fresh page request. You may first want to enable mod_expires and mod_headers , i use ubuntu so mine was
a2enmod headers && a2enmod expires && service apache2 restart
than you want to add below code to do minimum cache-control,
<IfModule mod_expires.c>
expiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType text/javascript "access plus 1 seconds"
ExpiresByType application/x-javascript "access plus 1 seconds"
</IfModule>
If you are using firefox you can test this by installing/running Live Http header Plugin or if you are linux/unix you can run this request with curl -v your_url
I'd like to access to a web application which requires spnego authentification.
This application is running on a network on which i'm connected by VPN connection. Proxy not used.
It works fine under IE6/7/8, Chrome but not firefox 3.6.13
The matter on firefox is: I don't have the prompt message box to enter username and password
To configure my FF, i applied the following instructions, adding the domain name to the trusted and delegation uris fields.
Trying to access to the application, i get the following error message:
A browser did not respond to authentication challenge sent by a server.
Most probably your browser is not configured properly to handle SPNEGO authentication challenge or does not support SPNEGO.
Please, contact your System Administrator to deal with the problem.
Using TCPMon to get an overview of the informations received:
GET /AppName HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/ HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
GET /AppName/logon HTTP/1.1
Host: app.domain:8182
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 ( .NET CLR 3.5.30729; .NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: JSESSIONID=6E058E24D9E1873C80B14C56EC59B1E4
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
Location: http://app.domain:8182/AppName/
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
0
HTTP/1.1 302 Déplacé Temporairement
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0
Location: http://app.domain:8182/AppName/logon
Content-Type: text/html
Content-Length: 0
Date: Tue, 14 Dec 2010 16:16:28 GMT
HTTP/1.1 401 Non-Autorisé
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
WWW-Authenticate: Negotiate
Connection: close
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 14 Dec 2010 16:16:28 GMT
4b9
I've checked for the other browsers and i got the same informations.
Do someone have an idea why FF can't interprete it, prompt a dialog box or enter the application ?
Thanks in advance for any help.
Best regards.
I'm having problems getting SharePoint 2010/IIS 7.5 to respect byte-range requests. I'm developing a SharePoint 2010 Web Part using Silverlight, and am trying to retrieve part of a document stored inside SharePoint.
When I request a byte range of a file in SharePoint, the server responds with the entire file. However, if I request the same byte range from a file sitting on an Apache server, everything works as expected. Below are the http headers observed with Fiddler.
Any help would be really appreciated! Thanks.
Sent:
GET http://example.com/file.abc HTTP/1.1
Accept: */*
Accept-Language: en-US
Referer: http://example.com/index.html
Accept-Encoding: identity
Range: bytes=1061285-1064594
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4
Host: example.com
Connection: Keep-Alive
SharePoint also takes login credentials:
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Received from Apache:
HTTP/1.1 206 Partial Content
Date: Wed, 25 Aug 2010 22:40:34 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 20 Aug 2010 23:27:18 GMT
ETag: "b68e346-103ea9-a3c20180"
Accept-Ranges: bytes
Content-Length: 3310
Vary: User-Agent
Content-Range: bytes 1061285-1064594/1064617
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: application/x-zip
Received from SharePoint 2010 / IIS 7.5
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Content-Length: 1064617
Content-Type: application/octet-stream
Expires: Tue, 10 Aug 2010 22:40:56 GMT
Last-Modified: Wed, 25 Aug 2010 19:28:39 GMT
ETag: "{5A1DF927-D8CD-4BC0-9590-8188CF777A3D},1"
Server: Microsoft-IIS/7.5
SPRequestGuid: 99799011-5bdc-489f-99fd-d060a56d3ae4
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
X-SharePointHealthScore: 5
ResourceTag: rt:5A1DF927-D8CD-4BC0-9590-8188CF777A3D#00000000001
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename=file.abc
X-Download-Options: noopen
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated={7703be10-bb56-4fa1-ba8b-cd05f482859f}; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.4762
Date: Wed, 25 Aug 2010 22:40:56 GMT
The problem is that SharePoint caching is off be default, and needs to be turned on to enable byte-range requests. See Disk-Based Caching for Binary Large Objects.
Note http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2:
"A server MAY ignore the Range header."
Thus whenever you are using a Range header you must be able to handle a 200 response. The fact that your server doesn't appear to support range serving is unfortunate, but conformant.