Получить URL загружаемой страницы

[failure]

Здравствуйте.

Помогите пожалуйста понять как лучше реализовать следующую задачу:

На странице есть форма, при сабмите аяксом отправляется на сервер, который после обработки возвращает новую страницу (контент) который помещается в текущую страницу.
От формы и наличия ошибок зависит какой контент (какой страницы) вернет сервер. После чего я меняю текущий URL (без перезагрузки) на тот, что и вернул бы браузер если бы форма отправлялось не аяксом (URL новой страницы), делаю это с помощью History API.

Когда страница грузится аяксом,например, после клика по ссылке, я беру URL из href.

Но как это сделать когда отправляется форма, и неизвестно заранее какая страница будет возвращена ?

Для понятности, примерный код обработки отправляемой формы, где errorPage() возвращает , допустим, текущую страницу с текстами ошибок, а newPage() - новую страницу, url которой нужно получить для работы в History API.

if ($_POST["form_name"]) {
 
  if (errors_exists($_POST)) return errorPage();
  else return newPage();
 
}

Думаю что в моём случае можно в форме создать input для хранения в нём URL новой страницы.
Может быть можно это реализовать лучше ?

[laimas]

меняю текущий URL (без перезагрузки) на тот, что и вернул бы браузер если бы форма отправлялось не аяксом (URL новой страницы)

Вы хотите сказать, что у вас множество страниц, у которых различны basename, все они имеют идентичные формы, но action которых ссылается на новый basename?

[failure]

laimas,
Так, но я не использую атрибуты "action" .

Пример для наглядности :

Есть страница /news - куда и нужно перенаправить после успешно обработанной формы (Перенаправления нет, ajax'ом беру контент и добавляю в активную страницу, вопрос в URL) .

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

Таким образом, при отправленной и успешно обработанной форме на странице "/addnew" - её контент сменится на тотже, что и на странице "/news", но URL останется прежним.

Как бы узнать адрес загружаемой страницы ?

[laimas]

я не использую атрибуты "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, имя которого для истории можно вернуть клиенту наряду с данными.

[failure]

laimas,

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

Я и так это делаю, работаю с историей. Для этого мне и нужен URL :

Таким образом, при отправленной и успешно обработанной форме на странице "/addnew" - её контент сменится на тотже, что и на странице "/news", но URL останется прежним.

Подумал сделать таким образом: в форму добавить флаг для определения сервером типа запроса, если как в моём случае, с необходимостью получения URL конечной страницы , то сервером и отдавать его ( json_encode(array("page_content" => $page, "url" => мой URL) ) .

Интересно было бы узнать, как подобное можно ещё реализовать.

[laimas]

в форму добавить флаг для определения сервером типа запроса

Какой флаг и какой тип? Тип запроса, это GET, POST, PUT, etc... У вас что запрашиваемое у сервера идентифицируется типом запросов? Что-то этого не наблюдается ни в коде, ни в описании к задаче. А следовательно сервер может идентифицирует операции только по параметрам запроса и скрытых полей для этого не требуется, тем более, что для клиента запрашиваемые параметры, это часть URL и должна отображаться в истории.

то сервером и отдавать его ( json_encode

А с другим типом данных кроме как JSON или XML, общение клиента с сервером будет затруднительно, если клиенту требуется получение не только данных, но и наличия ошибок или служебных данных.

[failure]

Какой флаг и какой тип?

Неправильно написал.
Флаг, например в input[type='hidden'] для определения по данным в запросе, нужно ли отдавать необходимый мне URL для последующей работы .

К примеру, если на конечную страницу с текущей не отправляется форма, то сервер отдаёт текстовый контент без url, иначе, если есть флаг (отправлена форма), то на сервере я помещу в ответ кроме контента страницы и нужный мне URL конечной страницы.

[failure]

Вопрос можно считать решённым, по моей идее всё работает как и нужно.

Но было бы интересно знать, если есть альтернативные решения.

[failure]

laimas, Rise,
Анализ заголовков также интересный вариант , спасибо.