Какое назначение имеет параметр & rnd = в запросах http? - PullRequest
6 голосов
/ 19 октября 2011

все!

Почему некоторые веб-приложения используют параметр http-get "& rnd ="? Какова цель этого? Какие проблемы решаются с помощью этого тега?

Ответы [ 4 ]

7 голосов
/ 19 октября 2011

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

Это также может быть отслеживание прогресса людей через сайт. Лучше всего объяснить с небольшой историей:

  1. Пользователь посещает example.com. Все ссылки имеют одинаковое случайное число (скажем, 4).
  2. Пользователь открывает ссылку в новом окне / вкладке, и ссылка - page2.php? Rnd = 4. Все ссылки на этой странице имеют случайное число 7.
  3. Пользователь может щелкнуть ссылку на page3.php на исходной вкладке или на новой вкладке, и аналитическое программное обеспечение на сервере может определить, какая из них имеет значение rnd = 4 или rnd = 7.

Все, что мы можем сделать, это предложить возможности. Нет единой стандартной причины для добавления rnd = в URL, и мы не можем знать мотивы дизайнера сайта, не увидев серверное программное обеспечение.

6 голосов
/ 19 октября 2011

Internet Explorer и другие браузеры будут считывать URL-адрес изображения, загружать изображение и сохранять его в кэше.

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

Следовательно, добавление случайной строки гарантирует, что она будет уникальной и будет загружаться в кэш каждый раз.

4 голосов
/ 19 октября 2011

Это почти всегда для очистки кэша.

2 голосов
/ 19 октября 2011

Как было предложено другими. Такое поведение обычно используется, чтобы избежать проблем с кэшированием при вызове страницы, которая возвращает данные динамического содержимого.

Например, скажем, у вас есть страница, которая получает некоторую текущую информацию о пользователе, такую ​​как «mysite.com/CurrentUserData». Теперь при первом обращении к этой странице пользовательские данные будут возвращены, как и ожидалось, но в зависимости от параметров синхронизации и кэширования второй вызов может вернуть те же данные - даже если ожидаемые данные могли быть обновлены.

Основная причина кеширования - это, конечно, оптимизация скорости частых запросов. Но в случае, когда это нежелательно, добавление случайного значения в качестве параметра строки запроса, как известно, является широко используемым решением.

Однако существуют и другие способы обойти эту проблему. Например, если вы выполняли Ajax-запрос с помощью javascript / JQuery. Вы можете установить кэш на false в вашем вызове ...

$.ajax({url: 'page.html', cache: false});

Вы также можете изменить его для всех вызовов страниц при загрузке документа с помощью ...

$.ajaxSetup({cache: false}});

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

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public ActionResult NonCacheableData()
{
    return View();
}

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

Осмелюсь сказать, что в IIS есть также настройки, которые вы можете применить для получения того же эффекта - хотя я еще не так далеко справился с этим.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...