В таких случаях параметры запроса подразумевают, что всегда изменяется . Если вы просто добавите &id=1123, это ничего не изменит.
Попробуйте добавить &t=nnnn с nnnn, например, равным текущему времени в секундах.
Или, если вы сгенерируете ссылку на том же сервере, лучше использовать * nnnn время модификации изображения в секундах или отметку времени:
?img.png&t=2019-07-04.17.03.22
UPDATE
Вы говорите, что как-то
http://www.server.com/get?img.png&id=1
и
http://www.server.com/get?img.png&id=2
обрабатываются браузером как одно и то же изображение. Я нахожу это трудным для принятия, потому что это будет (среди прочего) недостаток безопасности - это означает, что, скажем, get?report.pdf&user=whoknows&password=whatever может закончить загрузкой get?report.pdf&user=realuser&password=realpassword без необходимости предоставлять реальную информацию для входа во второй раз.
Совершенно не говоря, что это ваша вина (как разработчик, я часто оказывался в вашей конкретной ситуации), но кто-то здесь, кажется, где-то переусердствовал. Проблема в том, как точно определить, где и что вы можете сделать, если что-нибудь, с инструментами и доступом, которые вам были предоставлены.
Почему сервер может это делать, это объясняется проще всего: сервер или какая-то кеширующая система перед ним удаляет дополнительные параметры. Таким образом, вы можете спросить id = x273y3 столько, сколько захотите, чтобы эта информация никогда не доходила до сервера и не могла заставить ее что-либо делать. Было бы интересно узнать, каков был вариант использования для этого.
В некоторых ограниченных случаях вы можете сделать это с помощью уродливого хака - если вы запрашиваете 12345/../img.png вместо img.png, и разбор пути выполняется только правильным способом, то слой кэша может не кэшировать запрос и все же сервер все еще отвечает с более новым изображением. Но это хрупкий взлом, потому что множество законных изменений в архитектуре сервера может привести к его полному разрушению, в результате чего изображение вообще не отправляется.
Если вы боретесь с кэшированием на стороне сервера, то лучше попытаться добавить соответствующие прагмы без кэширования к самому запросу . Причина, по которой многие используют дополнительный взлом параметров, заключается в том, что из-за длительного злоупотребления клиентами несколько серверов кэширования могут и часто настраиваются на игнорирование этих заголовков.
Особенно, если кто-то зашел так далеко, как разбор параметров, он должен был вместо этого должным образом поддерживать директивы кэша.
(С другой стороны, если у вас есть сервер, который игнорирует и законных заголовков и запрашивает хаки, у вас есть достаточно веские доводы в пользу того, что бы ни случилось у них на голове).
В противном случае может случиться так, что клиент считает, что он может кэшировать ресурс, потому что он был отправлен с определенными заголовками ресурса (ETag и т. Д.), И повторная проверка кэша не завершается должным образом из-за клиента / непонимание сервера, что тоже случается довольно часто. Вы должны записать полный набор разговоров и опубликовать их здесь, чтобы помочь описать проблему:
- заголовки первого запроса к изображению
- заголовки ответа
- заголовки запроса к изображению, которое тем временем изменилось
- заголовки ответа на этот вопрос
Это также может быть что-то очень простое, например, сервер на самом деле отвечает фиксированным 302, который лишает дополнительных параметров. Затем кешируется новый URL:
GET /get?img.png & ...
302 Расположение: http://static -images.server.com / images / img.png
Это может произойти из-за слишком тщательного правила перезаписи движка переписывания сервера Apache, например, где "\? (. *. (Png | jpg | gif))" взято из исходного запроса и переписано в "NewLocation / $ 1". В таком случае другой хрупкий обходной путь будет заключаться в том, чтобы запросить /get?img.png?t=12345.png с двумя ?, чтобы обмануть механизм перезаписи для захвата img.png? T = 12345 вместо просто img, включая кеш разорение.
Однако правильное, хотя и более длительное, исправление состоит в том, чтобы переписывать людей и кеш, с которыми они общались и сотрудничали, вместо того, чтобы работать с разногласиями.