Bug 94844 – [Mac] WebKit should be caching POST responses in memory only

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Page Loading

[Jon Lee]

<rdar://problem/12146295>

[Jon Lee]

Created attachment 160283 [details]
Patch

[Sam Weinig]

Jon, Can you please add a description in the bug about why this is necessary?

[Jon Lee]

The HTTP 1.1 spec states that POST requests generally are not cacheable. (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) But for back/forward navigation we want to avoid showing the nag sheet, and show even stale responses (a behavior that is seen in other browsers such as Firefox). In order to do so we need to cache the response.

It is possible, however, that the response will end up being cached on disk, which might be undesirable for sensitive sites such as banks. Since cached POST responses are being used for back/forward navigation only, it would be more conformant to have those responses available only in memory.

The spec does make exceptions for POST responses that "include appropriate Cache-Control or Expires header fields", so I will need to revise my patch to look for those headers.

[Darth]

Hopefully nothing else breaks due to POST response caching, we recently encountered an issue in Safari 6 and there are also reports about iOS 6 webkit version:

http://stackoverflow.com/questions/12506897/is-ios6-safari-caching-ajax-results
http://arstechnica.com/apple/2012/09/developers-claim-safari-in-ios-6-breaks-web-apps-with-aggressive-caching

[Brady Eidson]

(In reply to comment #4)
> Hopefully nothing else breaks due to POST response caching, we recently encountered an issue in Safari 6 and there are also reports about iOS 6 webkit version:
> 
> http://stackoverflow.com/questions/12506897/is-ios6-safari-caching-ajax-results
> http://arstechnica.com/apple/2012/09/developers-claim-safari-in-ios-6-breaks-web-apps-with-aggressive-caching

Darth, both of those links discuss iOS6.  Can you link to a description of what you've seen with Safari 6.0.1?

[Darth]

I don't have an external test case for it, but showing some screenshots below.
The issue I encountered was more related to a change in behavior in Safari 6 vs prior Safari and other browsers.

http://i.imgur.com/aViQr.png
This image shows Safari 6 (webkit 536.25).
Notice in the image lots of XHR POSTS "getjobresult" - which is a request made to log into a bank in our case.
Normally there should not be more than 2-4 of such requests (unless a bank is down) because one of the responses will suggest that log into the bank was successful, but since the request never goes out (see the apache log and notice only 1 POST for getjobresult) it never gets a fresh response, as a result it keeps trying till eventually an error occurs. In our case it looks like as if bank is down. Also notice how web inspector says "No" in the cached column.

http://i.imgur.com/pnS9S.png
This image is from webkit nightly (webkit 537.12).
Nothing has changed from our backend and the same test as above.
Notice how both the apache log as well as web inspector shows the same exact number of requests for "getjobresult" and in this case everything works fine.

http://i.imgur.com/E61LM.png
This image shows the response header, which is identical for both Safari 6 and webkit nightly (and other browsers).
As you will see that there are cache headers, but our apache server has been putting these for many many months now, and this issue only started with Safari 6 and even webkit nightly seems fine.

We have fixed this issue at our end by removing the expires headers for the response and then Safari 6 starts to work fine.
I have however not tried putting max-age=0 to check if that still casuses an issue in Safari 6 just like the link from stackoverflow said for the iOS counterpart which is webkit 536.26

Also something similar
http://code.google.com/p/chromium/issues/detail?id=130797

(BTW off topic please please revert your web inspector to the prior UI design, the current one is so anti-Apple and confusing. Chrome's web inspector seems far simpler and better when it comes to debugging)

[Darth]

After updating to 10.8.2, safari 6.0.1 webkit 536.26.14, I cannot reproduce our issue, thanks for the heads up.