1. дома
  2. Вопрос и ответ
  3. Forward URL и еще вернуться 200 не 302 в ASPX

Forward URL и еще вернуться 200 не 302 в ASPX

2008-10-28 8 views
0

Я хочу эту страницу, чтобы вернуть 200 в то время как все еще посылает перенаправлять ...Forward URL и еще вернуться 200 не 302 в ASPX

<script> 
    sub page_load 
     'Get the parameters 
     dim content As String 
     content = request.querystring("text") 
     response.redirect ("http://100.200.100.10/test1/Default.aspx?CommandParm=" + content) 
    end sub 
</script> 
<html> 
    <head> 
    </head> 
    <body> 
     <form runat="server"> 
     </form> 
    </body> 
</html>

источник

2008-10-28 Anonymous

ответ

0

Ни в коем случае с Response.Redirect(). Я думаю. Возможно, установка Response.Status = "200 OK" после звонка Redirect() работ, я никогда не пробовал.

Вы можете подделать его, установив заголовок «Местоположение» вручную в противном случае пустым ответом. Не уверен, что это хорошо. ;-)

Response.AddHeader("Location", "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content) 
Response.End()

(И для записи: Вы бы производить недопустимую группировку заголовка HTTP ничего не должен ломаться, но все же.).

источник

2008-10-28 06:00:04 Tomalak

1

Вы можете получить эту страницу, чтобы быть перенаправлен по яваскрипта

Во-первых, создать динамический JavaScript, сделав следующую строку

<script type"text/javascript"> 
<!-- 
function redirect() 
{ 
    window.location = "http://100.200.100.10/test1/Default.aspx?CommandParm=" + content 
} 
//--> 
</script>

Во-вторых, добавьте Javas cript в заголовок текущей страницы.

Затем добавить JavaScript для тела

mybody.Attributes.Add("onload", "redirect()");

При просмотре текущей страницы, то он вернет вам HTTP 200, и после того, как OnLoad события запускает браузер вызовет перенаправление() и ваш просмотр будет в целевой страницы.

Любопытно, зачем это нужно ?!

источник

2008-10-28 06:10:49

+0

Спасибо. Я знаю, что это глупо. Но HTTP-запрос имеет ряд параметров, на которые я не могу влиять. Приложение, к которому я перенаправляю, может принимать только один именованный аргумент. Поэтому я по существу продвигаюсь к другому URL-адресу. Не имейте опыта аспирации, так что в темноте. – 2008-10-28 07:29:21

2

@ eyelidlessness @

Я согласен, что это похоже на плохой выбор практичности, но я надеюсь, что это временное решение проблемы, которая не может быть фиксированной непосредственно.

Учитывая, что, попробуйте META refresh, например,

<meta http-equiv="refresh" content="5;url=http://example.com/"/>

и встраивать сообщение объясняя, что происходит на незадачливый пользователь, который приземляется на этой странице.

Я, вероятно, не объяснял себя при размещении вопроса. Это фактически транзакция B2B. В браузере нет конечного пользователя. Третья сторона отправляет HTTP GET. Все, что мы хотим сделать, это отправить его как лигитимую транзакцию.

Затем вы должны отправить 301 или 302 - это точная цель, с которой они были предназначены для обработки.

источник

2008-10-28 10:00:38

+0

Я, вероятно, не объяснял себя при публикации вопроса. Это фактически транзакция B2B. В браузере нет конечного пользователя. Третья сторона отправляет HTTP GET. Все, что мы хотим сделать, это отправить его как лигитимую транзакцию. – 2008-10-28 10:52:14

1

Вы не можете иметь его как: Перенаправление и статус 200.

RFC2616 говорит о status code 200:

10.2.1 200 OK

Запрос удалось.Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например:

  • GET: субъект, соответствующий запрошенному ресурсу посылается в ответ;
  • HEAD: поля заголовка объекта, соответствующие запрашиваемому ресурсу, отправляются в ответе без какого-либо тела сообщения;
  • POST: объект, описывающий или содержащий результат действия;
  • TRACE: объект, содержащий сообщение запроса, полученное конечным сервером.

Так что нет места для перенаправления, кроме отправки некоторого содержания, которое интерпретируется пользовательским агентом, например, JavaScript в браузере.

И this is the part в спецификации, которая говорит о перенаправлении с использованием кодов состояния 301, 302 или 303:

10.3.2 301 Moved Постоянно

Запрошенный ресурс был назначен новый постоянный URI и любые будущие ссылки на этот ресурс ДОЛЖНЫ использовать один из возвращенных URI. Клиенты с возможностями редактирования ссылок должны автоматически перенаправить ссылки на Request-URI на одну или несколько новых ссылок, возвращаемых сервером, где это возможно. Этот ответ можно кэшировать, если не указано иное.

Новый постоянный URI ДОЛЖЕН быть предоставлен полем местоположения в ответе. Если метод запроса не был HEAD, сущность ответа СЛЕДУЕТ содержать короткую гипертекстовую ноту с гиперссылкой на новый URI (ы).

Если код статуса 301 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос было выпущено.

Примечание. При автоматическом перенаправлении запроса POST после получения кода состояния 301 некоторые существующие пользовательские агенты HTTP/1.0 будут ошибочно изменять его в запрос GET.

10.3.3 302 Найдено

Запрошенный ресурс временно находится под другим URI. Так как перенаправление может быть иногда изменено, клиент ДОЛЖЕН продолжать использовать Request-URI для будущих запросов. Этот ответ может быть только кэшируемым, если указано полем Cache-Control или Expires.

Временное URI ДОЛЖНО указываться полем «Местоположение» в ответе. Если метод запроса не был HEAD, сущность ответа СЛЕДУЕТ содержать короткую гипертекстовую ноту с гиперссылкой на новый URI (ы).

Если код статуса 302 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос было выпущено.

Примечание: RFC 1945 и RFC 2068 указывают, что клиенту не разрешено изменять метод по перенаправленному запросу. Однако большинство существующих реализаций пользовательских агентов обрабатывают 302, как если бы это был ответ 303, выполняя GET по значению поля Location независимо от исходного метода запроса. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.

10.3.4 303 См Другое

Ответ на запрос может быть найден под другим URI и ДОЛЖЕН быть получены с использованием метода GET по данному ресурсу. Этот метод существует прежде всего для того, чтобы позволить выходному скрипту, инициированному POST, перенаправлять агент пользователя на выбранный ресурс. Новый URI не является заменой ссылки на первоначально запрошенный ресурс. Ответ 303 НЕ ДОЛЖЕН кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.

Разный URI ДОЛЖЕН быть задан полем местоположения в ответе. Если метод запроса не был HEAD, сущность ответа СЛЕДУЕТ содержать короткую гипертекстовую ноту с гиперссылкой на новый URI (ы).

Примечание. Многие пользовательские агенты до HTTP/1.1 не понимают статус 303. Когда взаимодействие с такими клиентами вызывает озабоченность, вместо этого может использоваться код состояния 302, так как большинство пользовательских агентов реагируют на ответ 302, как описано здесь для 303.

источник

2008-11-03 20:12:11 mkoeller

 Смежные вопросы

  • Нет связанных вопросов^_^