Пока вы заботитесь об управлении кешем с помощью заголовков HTTP, вы должны посмотреть, использует ли клиент HTTP 1.1 или HTTP 1.0, а также есть ли прокси между ними или нет.
Чтобы вообще указать, что ресурс не должен кэшироваться, вы можете рассмотреть следующие заголовки:
header("Pragma: no-cache"); # HTTP 1.0
header("Cache-Control: no-cache"); # HTTP 1.1
header("Expires: Thu, 01 Dec 1994 16:00:00 GMT");
# With the two above, the last is not strictly necessary. Prefer a HTTP date in
# the past instead of -1 -OR- prefer 0 as it is specified how to deal with it.
Что можно кэшировать и как, см. Раздел 13.4 Кэшируемость ответов , а конкретные заголовки см. Протокол передачи гипертекста - HTTP / 1.1 Раздел 14 Определения полей заголовка .
Установка правильных заголовков не означает, что вы фактически полностью контролируете кеш браузера. Единственный, кто может это сделать, - пользователь, запускающий клиент. Любой клиент может быть настроен на игнорирование этих заголовков и просто кеширование сразу. Например. предварительно загруженный контент, что угодно.
Единственное, что вы можете сделать, это изменить URI ресурса (изображение профиля в вашем случае). Например. каждый раз, когда пользователь меняет свое изображение профиля, вы можете подсчитать счетчик ревизий и добавить его в URI. Это позволит гарантировать, что когда браузер запрашивает исправленное местоположение изображения профиля, будет отображаться правильное изображение.
В случае, если запрашивается старая ревизия, вы должны перенаправить на последнюю ревизию. Ответы на перенаправление чаще всего не кэшируются.
Использование ревизий поможет тем, что пользовательские агенты все еще будут кэшировать изображения (что хорошо для вашей пропускной способности и производительности страниц), в то время как они всегда будут отображать последнюю ревизию.