VGTech is a blog where the developers and devops of Norways most visited website share code and tricks of the trade… Read more

Are you brilliant? We're hiring. Read more

iOS7-bug: Shows white page when getting 304 Not Modified from server


It seems like after Apple upgraded almost every line of code in the iPhone they also introduced a bug regarding browser cache in Safari.

If your site takes advantage of the Last-Modified or ETag headers, you will probably run into this problem as well.

The iPhone will send a If-Modified-Since or If-None-Match header. The problem appears when the page is interrupted or cancelled during loading. In this case, it seems it will store an incomplete cache entry in the browser cache.

On the next request, it will try to read from cache, find a Last-Modified or ETag entry and send an If-Modified-Since or If-None-Match header. The server correctly responds with a 304 Not Modified, and the browser attempts to serve the page from cache. Unfortunately, the cache entry is incomplete and the result is a blank/white page.

There are multiple ways of cancelling the request; poor connection, double taps on the refresh button etc. See the YouTube-video for a demonstration.

The problem exists in the latest iOS7 at the time of writing (7.0.2) and has existed since the beta.

This is how we fixed the problem at VG

In front of all our web servers we use Varnish. Varnish handles every end-user request, asks the backend and caches the content. To ensure that iOS7-users does not end up with blank pages, we have to deliver a 200 OK even where a 304 Not Modified would be the correct response. To do this, we created a Varnish rule which removes the If-Modified-Since and If-None-Match headers on request and then have Varnish deliver the content as normal. This rule only applies to iOS7-devices, since this is where we know the problem exists.

We made a short video illustrating the problem below:

Hopefully, Apple will push an update that fixes this problem soon so we can remove the workaround and optimize the loading of our websites.

My name is Ole-Kenneth. I'm a web developer at VG.  @olekenneth


  • IOS 7 showing a Blank View on 304 Not-Modified Server response | BlogoSfera

    […] […]

  • Kelley Reynolds

    This problem also occurs with Safari and seemingly has for a while. If you land on a page that gives you a 304, it appears to read from the cache properly but then cache the empty body from the 304 to serve up the next time you hit refresh. I don't think its related to incomplete downloads or a canceled request, I think it just caches the body of the 304 when it shouldn't be.

  • Maxim

    Thanks dude, thats what I did in nginx to solve this problem:

    if ($http_user_agent !~* "iPhone OS 7") {
    expires max;

  • Diego

    I"m curious, has this been fixed as of 7.0.4? I tried your example from the YouTube video, and could not reproduce it on 7.0.4. So I'm either not seeing it, and it's still there, or it's been fixed. Or maybe it's been fixed by a change at

    • Ole-Kenneth Rangnes

      No, this is still an issue. I've reported it to Apple, but I haven't heared back.

  • Diego

    I wonder if there's a fix from an iOS app's side. I'm seeing the problem in my app and trying to find a solution. I will continue searching. Thanks for the post.

    • Ole-Kenneth Rangnes

      Yeah, I think so. I'm not an expert, but you should be able to disable the cache for the webview.

  • Even

    Might this be the same as this old wontfix:

  • Andrew

    Ahh thanks for this! I thought I was going mad.

  • Matti Järvinen

    It's not the same

    If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.

  • Lars

    Thank you, this was a bug I was experiencing due to W3 Total Cache and its Page Cache feature. Very nice!

Leave your comment