Сообщение от failure
|
я не использую атрибуты "action"
|
А я говорю как раз о случае обычной отправки, не асинхронной, что и цитируется, вами же написанное. Как в реальности такой механизм будет работать:
1) данные, как и их ключи, при передаче методом POST браузером не кешируются и в URL не отображаются. Адресом в данном случае будет адрес указанный в action формы.
2) передавая форму методом POST, одновременно можно передать и GET параметры, указав их в action формы. При этом браузер будет интерпретировать каждый новый набор параметров ключ=>значение, как обращение к новой странице.
3) в отличие от браузера для сервера набор GET параметров не означает обращение к новому файлу обработчику. Файл обработчик, это basename переданного в URL, а GET параметры, это только параметры, которые скрипт basename должен обработать.
К примеру, обращения к индексному файлу как:
index.ext
index.ext?a=1
index.ext?b=2
для сервера означают, что обращаются всегда к index.ext, а как различия URL в этих запросах, для сервера имеют значения только как referer. И только в случае, если клиентом будет указано иное, будет обращение к иному файлу скрипту.
Предположим, что в зависимости от значения какого либо GET/POST параметра, сценарий индексного файла перенаправляет клиента на другую страницу. Для этого передается заголовок header("location: url"), который будет принят браузером, и который сделает запрос по указанному заголовком адресу, отображая естественно URL, который естественно попадает в историю.
Если же асинхронные запросы, то в историю нужно самостоятельно передавать параметры запросов, а в случае перенаправлений сервером анализировать заголовки им переданные.
PS. Если в асинхронном режиме работы сервер не делает перенаправлений при определенных параметрах запроса, а в basename подключается новый файл, то сохраненные в истории параметры запроса и есть обращение к новому basename, имя которого для истории можно вернуть клиенту наряду с данными.