Вы не можете запретить всем браузерам показывать это "Вы уверены, что хотите повторно отправить эту форму?" всплывающее окно, когда пользователь обновляет страницу, которая является результатом запроса POST. Поэтому вам нужно будет превратить этот запрос POST в запрос GET, если вы хотите запретить это всплывающее окно, когда ваши пользователи нажимают клавишу F5 на этой странице.
И для формы поиска, для которой вы вроде бы признали, что превращение POST в GET имеет свои проблемы.
Для начала, вы уверены, что вам нужно POST для начала? Действительно ли данные слишком велики для размещения в строке запроса? Принимая разумный предел в 1024 символа , составляющий около 30 GUID (дайте или возьмите некоторое пространство для повторного &q=), зачем вам сначала нужно, чтобы параметры поиска были GUID? Если вы можете сопоставить их или найти их каким-либо образом, вы можете ограничить размер каждого параметра несколькими символами вместо 32 для не пунктирного идентификатора GUID, а с 5 символами на ключ вы можете внезапно уместить 200 параметров в запросе. строка.
Все еще недостаточно? Тогда вам действительно нужен POST.
Один из упомянутых в комментариях подходов использует AJAX, поэтому ваша поисковая форма фактически не отправляет, а вместо этого отправляет данные запроса в фоновом режиме через * 1088. * HTTP POST запрос и обновляет страницу с результатами. Преимущество в том, что обновление страницы не вызывает запроса, поскольку браузер имеет только GET, но есть один недостаток: результаты поиска не получают уникальный URL, поэтому вы не можете кэшировать , добавьте в закладки или поделитесь их.
Если вас не волнует кэширование или создание закладок URL, тогда AJAX определенно является самым простым вариантом, и вам не нужно читать дальше.
Для всех подходов, отличных от AJAX, вам необходимо сохранить параметры запроса где-нибудь, включая шаблон Post / Redirect / Get. Этот шаблон заканчивается страницей, которая является результатом запроса GET, который пользователи могут обновить sh без указанного всплывающего окна. Что другие ответы довольно handwavy о, это как , чтобы правильно сделать это.
Варианты:
Сеанс сервера
При размещении на сервере вы можете позволить серверу сохранять параметры запроса в сеансе (все основные серверные инфраструктуры позволяют использовать сеансы), а затем перенаправить пользователя на общую страницу c /search-results, которая на серверная сторона считывает данные из сеанса и предоставляет пользователю результаты, полученные на основе запросов к базе данных, в сочетании с параметрами запроса из сеанса.
Недостатки:
- Время сеансов обычно истекло И делают это по уважительным причинам. Если ваш пользователь нажимает F5, скажем, через 20 минут, его данные сеанса исчезают, как и параметры запроса.
- Сессии распределяются между вкладками браузера. Если ваш пользователь ищет элемент A на вкладке 1 и элемент B на вкладке 2, параметры вкладки, которая была отправлена последней, перезапишут более ранние вкладки при их обновлении.
- Сессии для браузера. Как правило, нет простого способа поделиться сеансами (кроме помещения идентификатора сеанса в URL, но см. Первый маркер), поэтому вы не можете добавить в закладки или поделиться результатами поиска.
Локальное хранилище / куки
Вы можете подумать, что «куки могут содержать больше данных, чем строка запроса», но просто нет. Помимо наличия ограничения, они также разделяются между вкладками и не могут (легко) делиться между пользователями и не добавляются в закладки.
Локальное хранилище также не вариант, потому что пока оно может содержать гораздо больше данных - они не отправляются на сервер. Это локальное хранилище.
Серверное постоянное хранилище
Если ваши поисковые запросы на самом деле настолько сложны , что вам требуется несколько КБ параметров запроса, то вы возможно выиграет от сохранения параметров запроса в базе данных.
Таким образом, для каждого поискового запроса вы создаете новую запись базы данных search_query, которая содержит соответствующие параметры для запроса на выполнение, и, учитывая, что результаты поиска не являются частными, вы можете даже написать некоторый код, который ищет использовалась ли данная комбинация параметров ранее и сначала выполняется поиск.
Таким образом, вы получаете уникальный search_id, который указывает на набор параметров, с которыми вы можете выполнить запрос. Теперь вы можете перенаправить своих пользователей, чтобы они выполняли запрос GET на эту страницу:
/search-results?search_id=Xxx
И там вы отображаете результаты для данного запроса. Преимущества:
- Вы можете кэшировать, добавить в закладки и поделиться URL-адресом
/search-results?search_id=Xxx - Вы можете обновить sh страницу, отображающую результаты поиска без раздражающего всплывающего окна
- Каждая вкладка браузера отображает свои собственные результаты поиска
Конечно, у этого подхода также есть недостатки:
- Если вы не используете неугадываемый ключ для
search_id, пользователи могут перечислять ранее поиск других пользователей - Каждый поиск требует постоянного серверного хранилища, если только вы не решите исключить более ранние поиски на основе некоторых критериев