покажите, что “веб-страница истекла” на кнопке "Назад"
Ключ к успешному поблочному тестированию разъединение . Необходимо разделить интересный код от его внешних зависимостей, таким образом, он может быть протестирован в изоляции. (К счастью Разработка через тестирование производит разъединенный код.)
В этом случае, Вашим внешним является текущий DateTime.
Мой совет здесь состоит в том, чтобы извлечь логику, которая имеет дело с DateTime к новому методу или классу или независимо от того, что имеет смысл в Вашем случае, и передайте DateTime в. Теперь, Ваш модульный тест может передать произвольный DateTime в, для приведения к предсказуемым результатам.
3 ответа
Ну, по умолчанию всякий раз, когда вы имеете дело с формой POST, а затем пользователь нажимает ответ, а затем обновляет, тогда они увидят сообщение, указывающее, что браузер повторно отправляет данные. Но если страница настроена на немедленное истечение срока действия, им даже не нужно будет нажимать кнопку «Обновить», и они увидят сообщение об истечении срока действия страницы, когда они ответят.
Чтобы избежать появления обоих сообщений, можно попробовать следующее:
1) Вместо этого используйте форму GET. Это зависит от того, что вы делаете, но это не всегда хорошее решение, поскольку все еще существуют ограничения по размеру для запроса GET. И информация передается в строке запроса, что не является самым безопасным из вариантов.
- или -
2) Выполните перенаправление на стороне сервера на другую страницу после формы POST.
Похоже, здесь был дан ответ на аналогичный вопрос:
В качестве третьего варианта можно запретить пользователю вернуться в свой браузер. вообще. Единственный раз, когда я почувствовал необходимость это сделать, было помешать им сделать что-то глупое, например заплатить дважды. Хотя есть более эффективные методы на стороне сервера, чтобы справиться с этим. Если на вашем сайте используются сеансы, вы можете запретить им платить дважды, сначала отключив кеш на странице оформления заказа и установив срок его действия немедленно. А затем вы можете использовать какой-то флаг, хранящийся в сеансе, который фактически изменит поведение страницы, если вы вернетесь к ней.
Будет ли это работать, если байтов больше, чем может обработать запрос GET?В качестве третьего варианта можно вообще запретить пользователю возвращаться в свой браузер. Единственный раз, когда я почувствовал необходимость это сделать, было помешать им сделать что-то глупое, например заплатить дважды. Хотя есть более эффективные методы на стороне сервера для этого. Если на вашем сайте используются сеансы, вы можете запретить им платить дважды, сначала отключив кеш на странице оформления заказа и установив срок его действия немедленно. А затем вы можете использовать какой-то флаг, хранящийся в сеансе, который фактически изменит поведение страницы, если вы вернетесь к ней.
Будет ли это работать, если байтов больше, чем может обработать запрос GET?В качестве третьего варианта можно вообще запретить пользователю возвращаться в свой браузер. Единственный раз, когда я почувствовал необходимость это сделать, было помешать им сделать что-то глупое, например заплатить дважды. Хотя есть более эффективные методы на стороне сервера, чтобы справиться с этим. Если на вашем сайте используются сеансы, вы можете запретить им платить дважды, сначала отключив кеш на странице оформления заказа и установив срок его действия немедленно. А затем вы можете использовать какой-то флаг, хранящийся в сеансе, который фактически изменит поведение страницы, если вы вернетесь к ней.
Хотя есть более эффективные методы на стороне сервера, чтобы справиться с этим. Если на вашем сайте используются сеансы, вы можете запретить им платить дважды, сначала отключив кеш на странице оформления заказа и установив срок его действия немедленно. А затем вы можете использовать какой-то флаг, хранящийся в сеансе, который фактически изменит поведение страницы, если вы вернетесь к ней. Хотя есть более эффективные методы на стороне сервера, чтобы справиться с этим. Если на вашем сайте используются сеансы, вы можете запретить им платить дважды, сначала отключив кеш на странице оформления заказа и установив срок его действия немедленно. А затем вы можете использовать какой-то флаг, хранящийся в сеансе, который фактически изменит поведение страницы, если вы вернетесь к ней.вам необходимо установить параметр управления прагма-кешем в заголовках HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
Однако, с точки зрения удобства использования, такой подход к вопросу не рекомендуется. Я настоятельно рекомендую вам поискать другие варианты.
ps: как было предложено Стивом, перенаправление через GET является правильным способом (или проверять перемещение страницы с помощью JS).
Я не уверен, что это стандартная практика, но я обычно решаю эту проблему, не отправляя заголовок Vary только для IE. В Apache вы можете поместить следующее в httpd.conf:
BrowserMatch MSIE force-no-vary
Согласно RFC:
Значение поля Vary указывает на набор полей заголовка запроса, который полностью определяет, пока ответ свежий, разрешено ли кэшу использовать ответ для ответа на последующий запрос без повторной проверки.
Практический эффект заключается в том, что когда вы "возвращаетесь" к POST, IE просто получает страницу из кэша истории. Никакого запроса на стороне сервера не происходит. Я могу видеть это ясно в HTTPWatch.
Мне было бы интересно узнать о возможных плохих побочных эффектах такого подхода.