1) Visit http://html5demos.com/offlineapp 2) Turn off the network and reload the page" we should view the content again from appCache.But we can't see the content if http-cache is enabled.
Created attachment 116329 [details] patch patch
This doesn't look like correct approach. What platform did you observe the problem on, and what was the http status code in this scenario? When network is not reachable, cache should either return a cached response (and thus not fail), or never call didReceiveResponse() at all.
(In reply to comment #2) > This doesn't look like correct approach. What platform did you observe the problem on, and what was the http status code in this scenario? When network is not reachable, cache should either return a cached response (and thus not fail), or never call didReceiveResponse() at all. I am a developer of RIM's browser. And I found this issue in our browser. And safari has the same issue. http://html5demos.com/offlineapp when we try to view this site, webkit will preload html5demos.css, and http-cache will cache this css file. Then manifestParser will try to download html5demos.css again. But this time it will get the body from http-cache, and the status-code is 304. In this case appCache will call cacheUpdateFailed() because the status-code is not 200.
(In reply to comment #3) > (In reply to comment #2) > > This doesn't look like correct approach. What platform did you observe the problem on, and what was the http status code in this scenario? When network is not reachable, cache should either return a cached response (and thus not fail), or never call didReceiveResponse() at all. > > I am a developer of RIM's browser. And I found this issue in our browser. > And safari has the same issue. > > http://html5demos.com/offlineapp > when we try to view this site, webkit will preload html5demos.css, and http-cache will cache this css file. > Then manifestParser will try to download html5demos.css again. > But this time it will get the body from http-cache, and the status-code is 304. > > In this case appCache will call cacheUpdateFailed() because the status-code is not 200. So I don't think it is right to do this. we should treat 304 in this case as a success because the http-body is the data appCache need. What is your opinion? Thanks!
Comment on attachment 116329 [details] patch Safari does not have this issue. > But this time it will get the body from http-cache, and the status-code is 304. This is where the bug is. HTTP cache should not send a 304 over when first loading an appcache. It would be useless, as it has no data, it has different headers etc. This is something you need to fix in your network back-end for it to be usable with WebKit. I guess that you might be adding response body after 304, which made regular browsing work, but that's not how it's supposed to be implemented. Note that 304 can be returned when updating appcache (if HTTP cache doesn't have the response cached). That case is handled right above the line you modified in this patch.
(In reply to comment #5) > (From update of attachment 116329 [details]) > Safari does not have this issue. > > > But this time it will get the body from http-cache, and the status-code is 304. > > This is where the bug is. HTTP cache should not send a 304 over when first loading an appcache. It would be useless, as it has no data, it has different headers etc. This is something you need to fix in your network back-end for it to be usable with WebKit. I guess that you might be adding response body after 304, which made regular browsing work, but that's not how it's supposed to be implemented. > > Note that 304 can be returned when updating appcache (if HTTP cache doesn't have the response cached). That case is handled right above the line you modified in this patch. I find safari has this issue on windows not MAC. Did you try it on windows, too? And do you mean http-cache will only send 200 to webkit although 304 received? If we send 200 to webkit, inspector can't show 304 at all. Thanks for your reply.
> I find safari has this issue on windows not MAC. > Did you try it on windows, too? I did not try it on Windows, but the network back-end is the same there. I'd be quite surprised if it worked in a different way. Note that this example page is incorrect - it has a mistake in NETWORK section, so several images and scripts do not load. Perhaps this is what you are seeing? I'm also CC'ing the author of this page. > And do you mean http-cache will only send 200 to webkit although 304 received? > If we send 200 to webkit, inspector can't show 304 at all. Yes, 304 responses are completely hidden by the network layer, so Inspector cannot show them.
(In reply to comment #7) > > I find safari has this issue on windows not MAC. > > Did you try it on windows, too? > > I did not try it on Windows, but the network back-end is the same there. I'd be quite surprised if it worked in a different way. > > Note that this example page is incorrect - it has a mistake in NETWORK section, so several images and scripts do not load. Perhaps this is what you are seeing? > > I'm also CC'ing the author of this page. > > > And do you mean http-cache will only send 200 to webkit although 304 received? > > If we send 200 to webkit, inspector can't show 304 at all. > > Yes, 304 responses are completely hidden by the network layer, so Inspector cannot show them. But our inspector needs to show 304. And chrome can show 304.
You should find some other way to expose this data to Inspector. Generating invalid 304 responses with data is not the right way to do it in WebKit.
(In reply to comment #9) > You should find some other way to expose this data to Inspector. Generating invalid 304 responses with data is not the right way to do it in WebKit. Ok, thanks.
close it.