QNetworkAccessManager: отмена кеширования документа

[serg_hd]

Смысл в том, чтобы заставить NetworkAccessManager не кешировать конкретную картинку. Для этого перегружаю его метод createRequest(), который применяется ко всем незакешированным ресурсам страницы, ставлю в нём условие типа если myReq.url() (myReq наследует оригинальный request) равен url'у этой картинки, то сделать запрет на кеширование.
Собственно уже делал:
1) myReq.setRawHeader( new QByteArray("Cache-Control"), new QByteArray("no-cache") ); //другие заголовки переопределяются нормально, этот почему-то всё равно не влияет на отмену кеширования.
2) ставил также заголовок "If-Modified-Since" с датой раньше на пару дней (также даже раньше чем собственно 01.01.1970) - не помогло.
3) менял myReq.url() на myReq.url()+random():

Код

Java
myReq.setUrl(new QUrl(url2 + "&x=" + rand.nextInt(1000000)));
 

в надежде, что урл каждый раз будет разный и прога не будет обращаться к кешу, не проканало. Хотя если после этого проверить (myReq.url()), то он действительно изменённый с рандомом.
Также была куча других вариантов, не столь внушающих надежды как эти.
Интересно то, что если к адресу картинки в самом скрипте сайта добавить какой-нибудь random(), то картинка действительно не кешируется! Почему этого же не делает программа, вот что странно.
Также знаю что картинка отдаёт "Cache-Control:no-cache" и "Pragma:no-cache", так что с её стороны всё нормально. Не кешировать отдельно картинку надо для того, чтобы не отключать весь кеш, хотя в таком случае бы всё работало как надо, но сильно влияет на скорость работы, это и понятно.

[serg_hd]

Также не помогло закидываение реквеста с картинкой в NetworkAccessManager, который для QNetworkDiskCache выполняет setMaximumCacheSize(0).
QNetworkDiskCache наверно считается как "дополнительный" (если необоходимо) кэш? Т.к. указанный в setCacheDirectory() каталог он всё же создаёт.

[serg_hd]

Проблема, наверно, в том, что

Код

Java
myReq.setUrl(new QUrl(url2 + "&x=" + rand.nextInt(1000000)));
 

надо делать раньше чем в методе createRequest(), но вот где...
Кстати, если при new QUrl() будет какая-нибудь php-страница, то не кешируется даже без применения рандома.

[serg_hd]

Нахождение решения проблемы - $15. icq: 25-00-25-75пять

[ритт]

попробуй
req.setAttribute(QNetworkRequest::CacheSaveControlAttribute, false);
req.setAttribute(QNetworkRequest::CacheLoadControlAttribute, QNetworkRequest::AlwaysNetwork);

и в setUrl нужно не
myReq.setUrl(new QUrl(..))
а
myReq.setUrl(QUrl(..))

[serg_hd]

попробуй
req.setAttribute(QNetworkRequest::CacheSaveControlAttribute, false);
req.setAttribute(QNetworkRequest::CacheLoadControlAttribute, QNetworkRequest::AlwaysNetwork);

тоже пробовал, безрезультатно (забыл указать в первом посте, просто слишком много вариантов уже было)

и в setUrl нужно не
myReq.setUrl(new QUrl(..))
а
myReq.setUrl(QUrl(..))

Это в с++ наверное так, у меня jambi (java), там только через экземпляр объекта. Такое впечателине, что QNetworkAccessManager в первую очередь смотрит какой адрес нужен qwebview, а на программера внимания уже особо не обращает)). Меняй не меняй - как об стену.
Кстати, в с++ с этим кешированием отдельного ресурса страницы та же проблема, как в 4.5, так и в 4.6.

[serg_hd]

$20

[sendevent]

Также знаю что картинка отдаёт "Cache-Control:no-cache" и "Pragma:no-cache", так что с её стороны всё нормально.

Кстати, в с++ с этим кешированием отдельного ресурса страницы та же проблема, как в 4.5, так и в 4.6.

как проверял? или это маркетинговый ход?
win XP + nmake + Qt 4.6: если документ с сервера приходит с "no-cache" - он и не попадает в кеш изначально.
думаю, стоит разбераться, кто и когда сохраняет картинку - возможно, криво портирован сам вебкит.

[serg_hd]

проверяли также как и jambi: грузили одновременно неск. qwebview, каждая из которых была под своей прокси (чтобы mail.ru считал хосты, так наиболее удобно проверять - и результат налицо). Засчитывается всегда только 1й qwebview, остальные берутся уже из кеша. Т.е. сколько бы вы в проге qwebview не запустили, всегда будет только +1. Один компетентный (в чём я не сомневаюсь даже) программист, из этого форума 1.5 дня почти с этим тоже ковырялся (за что отдельное спасибо). Вывод пока остался один - это делает кеш самой webkit (не qwebkit, он только надстройка как известно). Никакие обходы пока найдены не были.

[ритт]

Оо
> Засчитывается всегда только 1й qwebview
можно подробнее?? и при чём тут кэширование?)

сейчас я склонен поверить sendevent на слово - что кэширование отрабатывает корректно...

[serg_hd]

Оо
> Засчитывается всегда только 1й qwebview
можно подробнее?? и при чём тут кэширование?)

При том, что остальные qwebview (точнее их NetworkAccessManager ) обращается для прорисовки этой картинки в кеш, а не в инет, несмотря на то, что картинка выдаёт cach-control:no-cache.
Это легко доказуемо, если прописать рандом к картинке со стороны скрипта сайта, в этом случае обращение всегда будет в инет и засчитываться будут все.

[ритт]

установка прокси совсем необязательно приводит к дополнительному унику )
я надеюсь, мы тут не про счётчик мэйл.рю говорим, нет?

[niXman]

установка прокси совсем необязательно приводит к дополнительному унику )

поясните пожалуйста.

я надеюсь, мы тут не про счётчик мэйл.рю говорим, нет?

если да, то и мне любопытно)

[serg_hd]

я надеюсь, мы тут не про счётчик мэйл.рю говорим, нет?

Нет, мы говорим об отмене кеширования любой картинки страницы сайта.
>>установка прокси совсем необязательно приводит к дополнительному унику )
что касается счётчика, то ему нужен уникальный ip, прокси это позволяет. Если есть другие приёмы - рад выслушать.

[ритт]

проверяли также как и jambi: грузили одновременно неск. qwebview, каждая из которых была под своей прокси (чтобы mail.ru считал хосты, так наиболее удобно проверять - и результат налицо). Засчитывается всегда только 1й qwebview, остальные берутся уже из кеша. Т.е. сколько бы вы в проге qwebview не запустили, всегда будет только +1. Один компетентный (в чём я не сомневаюсь даже) программист, из этого форума 1.5 дня почти с этим тоже ковырялся (за что отдельное спасибо). Вывод пока остался один - это делает кеш самой webkit (не qwebkit, он только надстройка как известно). Никакие обходы пока найдены не были.

я правильно понимаю, проверяли, загружая счётчик мэйл.рю, который накручивался лишь при первом обращении, из чего сделали вывод о кривости кэширования? или как-то ещё проверяли?