parserALT
Страницы форума: ← Назад | 1 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 600 | Дальше →

Правильный ответ на пост-запрос

#1rash
08.12.10 15:59
www.parser.ru → | ответить → | в избранное →

Правильный ответ на пост-запрос

В общем-то вопрос не специфичный для парсера, но тем не менее не решенный :(
В уроках на примере гостевой книги показано, что на пост-запрос надо отвечать перенаправлением (в примере использован location с текущим адресом). Это не работает — при обновлении страницы форма пытается переотправиться.
Пробовал заменить заголовком refresh — помогло везде, кроме фаерфокса (в ИЕ еще не смотрел). Добавление задержки перед рефрешем ничего не меняет — форма при обновлении пытается переотправиться.
Собственно, есть ли какое-то универсальное решение, как отвечать на пост-запросы, чтобы избежать случайной повторной отправки формы. Что-то вроде good practice.
#2rash
→ rash [#1] | 08.12.10 16:57
www.parser.ru → | ответить → | в избранное →

Странное поведение при установке заголовка рефреш

В процессе поиска временного решения создал страницу, которая просто редиректит на referer, однако и тут все работает не так гладко, как хотелось бы.

Заголовок устанавливается таким образом:
$response:refresh[
   $.value(5) 
   $.url[$env:HTTP_REFERER]
]

При этом браузер пытается перейти по адресу http://mysite.com/http://mystie.com/referer/uri
То есть путь интерпретируется как относительный. Если его указать явно, не используя значение переменной - все работает хорошо. Почему так может происходить, и как от этого избавиться?

И еще: можно ли как-нибудь явно указать статус ответа? В документации к классу response ничего не нашлось :(
#3
→ rash [#1] | 08.12.10 17:01
www.parser.ru → | ответить → | в избранное →

Это работает

показано, что на пост-запрос надо отвечать перенаправлением (в примере использован location с текущим адресом). Это не работает

Надо просто правильно перенаправлять. Заголовок Location: /uri (начинающийся со /) считается в apache внутренним редиректом и обрабатывается внутри apache, не доходя до пользователя. Поэтому надо либо выдавать $response:location[./] (./current-page.html), либо $response:location[http://полный url].
#4rash
08.12.10 17:17
www.parser.ru → | ответить → | в избранное →

Есть ли универсальный подход?

Спасибо, но все никак не станет на место.
Такое ощущение, что location сохраняет метод запроса.
$response:location[.$request:uri]

сначала перенаправляет на
site.com/address
методом пост, а затем на
site.com/address/address
уже методом гет.
Очевидно, что где-то моя ошибка, но никак не найду.

Попробую с рефрешем.
#5
→ rash [#4] | 08.12.10 17:33
www.parser.ru → | ответить → | в избранное →

Мда...

То, что начинается с . - это относительный путь, относительно текущего uri. Поэтом .$request:uri - это ерунда какая-то. Если uri /test1/test2/, то ./ - это /test1/test2/, ../ - это /test1/, ./test3/ или test3/ - это /test1/test2/test3/.
#6rash
08.12.10 19:05
www.parser.ru → | ответить → | в избранное →

Понятно

Вскорости после того, как спросил - понял, в каком месте туплю, спасибо, теперь окончательно разобрался с этим моментом.
Чтобы средиректить на текущую страницу без редиректа на уровне сервера использую ./
Изначально смутило, что в примере в учебнике используется $response:location[$request:uri]
при том, что в самой переменной содержится путь, начинающийся с / — таким образом редирект сработает на уровне сервера.

Однако такое объяснение работы с путями не снимает вопроса о том, почему
$response:refresh[
   $.value(5) 
   $.url[$env:HTTP_REFERER]
]

перенаправляет на http://mysite.com/http://mystie.com/referer/uri несмотря на то, что в $env:HTTP_REFERER содержится урл, начинающийся с протокола, а никак не с точки или слеша. При этом если http://mystie.com/referer/uri указать в виде литерала — все работает хорошо. Какой основополагающий принцип я не понимаю, если такое поведение мне кажется странным?

P.S: прошу прощения за такой поток однотипных вопросов, однако я не могу пользоваться како-то технологией или приемом, пока не буду понимать, как это работает, а найти описание тонкостей редиректа в интернете пока не получается.
#7
→ rash [#6] | 08.12.10 19:32
www.parser.ru → | ответить → | в избранное →

Надо $.url[^untaint{$env:HTTP_REFERER}]

#8rash
08.12.10 19:36
www.parser.ru → | ответить → | в избранное →
О, это уже лучше.
Но черт побери, почему?!! И то и то — корректный урл, если я правильно понимаю. Почему такое разное поведение?
#9rash
→ rash [#8] | 08.12.10 20:14
www.parser.ru → | ответить → | в избранное →
Кажется, понял.
Без untaint этот урл получится дважды урл-кодированным.
#10Alexei
→ rash [#1] | 09.12.10 16:28
www.parser.ru → | ответить → | в избранное →

$response:location[$env:SERVER_NAME/post/done/]

#11Забыл
→ rash [#1] | 15.12.10 22:32
www.parser.ru → | ответить → | в избранное →

Делаете уникальный идентификатор и сохраняете его...

в БД, файл (см. Hashfile) или еще куда.

Потом смотрите, если пришел (идент.) -- то сохранять (обновлять и т. д.) ничего не нужно.
#12Забыл
→ rash [#2] | 15.12.10 22:33
www.parser.ru → | ответить → | в избранное →

Забудьте про Refresh, толку от него мало

#13rash
→ Забыл [#12] | 15.12.10 23:15
www.parser.ru → | ответить → | в избранное →
А почему? В смысле, за счет чего снижается его полезность?
Просто хочется не только следовать рекомендациям, но и понимать их причины.
#14rash
→ Забыл [#11] | 15.12.10 23:17
www.parser.ru → | ответить → | в избранное →
Это необходимое но не достаточное действие при обработке пост-данных от формы.
Это предотвратит повторное выполнение обработки, а для пользователя полезно еще и подавить назойливый запрос браузера на переотправку формы при обновлении страницы.
#15Забыл
→ rash [#14] | 16.12.10 20:48
www.parser.ru → | ответить → | в избранное →

Еще полезно за него форму заполнить,

т. е. ту ее часть, когда он не всю заполнил и мы ему опять ее показываем.
#16rash
→ Забыл [#15] | 16.12.10 20:50
www.parser.ru → | ответить → | в избранное →
Это тоже из разряда обязательных пунктов в чек-листе :)
Если форма не может быть обработана — не терять данные из нее, а позволить исправить.
#17Забыл
→ rash [#13] | 16.12.10 20:54
www.parser.ru → | ответить → | в избранное →

Локэйшн это стандартная команда от сервера к клиенту

HTTP/1.1 302 Found
Location: http://www.wikipedia.org/index.php
, а рефреш
<meta http-equiv="refresh" content="5;url=http://example.com/" />
, отголосок простого клиентского (браузерного) редиректа, с выключенным JS, например.
#18Забыл
→ rash [#16] | 16.12.10 20:55
www.parser.ru → | ответить → | в избранное →

А чем вас уникальный айдишник не устраивает?

#19rash
→ Забыл [#18] | 16.12.10 21:03
www.parser.ru → | ответить → | в избранное →
Наверное я не понимаю чего-то, но разве ID запроса к обработчику формы и предзаполнение ее данными после ошибки — взаимоисключающие вещи?
#20Забыл
→ rash [#1] | 16.12.10 21:09
www.parser.ru → | ответить → | в избранное →

Не мучайте себя, пользователь может нажать кнопку "назад", тогда ни GET ни POST не спасет...

Обобщенно, если хочется с location:

$error(0)

^if(def $form:data && (def $form:action && $form:action eq "save") && ^not_in_db[$form:guid_marker]) {
    ^if(^save_data[$form:data;$form:guid_marker] eq 1){
        ^location[${address}?saved=yes]
    }{
        $error(1)
    }
)

^if(def $form:saved){
   ^print_ok[]
}{
    ^print_form[$form;$error]
}
#21Забыл
→ rash [#19] | 16.12.10 21:10
www.parser.ru → | ответить → | в избранное →

«Правильный ответ на пост-запрос [Не мучайте себя, пользователь может нажать кнопку "назад", тогда ни GET ни POST не спасет...]»

#22Забыл
→ rash [#4] | 16.12.10 21:44
www.parser.ru → | ответить → | в избранное →

Может быть

@location[address][_request;_base]
$_request[$request:uri]
#use $env:SERVER_NAME if "UseCanonicalName" is "Off"
$_base[^getServerProtocol[]://$env:SERVER_NAME]
#stop recursion redirect
^if(def $address){
	^if($_request ne $address || $env:REQUEST_METHOD eq "POST"){
		$response:location[${_base}^taint[as-is][$address]]
	}
}

@getServerProtocol[][s]
$s[^env:SERVER_PROTOCOL.mid(0;5)]
$s[^s.lower[]]
$s[^s.trim[right;/]]
$result[^if(def $s){$s}{http}]
Страницы форума: ← Назад | 1 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 600 | Дальше →