Поддержка заголовка" Expect: 100-continue " с помощью ASP.NET MVC

я реализую REST API, используя ASP.NET MVC, и небольшой камень преткновения придумал в виде Expect: 100-continue заголовок запроса для запросов с тела.

RFC 2616 гласит:

при получении запроса, который включает заголовок запроса Expect поле с ожиданием" 100-continue", исходный сервер должен либо ответьте со статусом 100 (ПРОДОЛЖИТЬ) и продолжайте читать от входа поток, или ответьте с окончательным кодом состояния. Этот исходный сервер не должен ждать тело запроса перед отправкой ответ 100 (продолжение). Если он отвечает с окончательным статусом код, он может закрыть транспортное соединение или продолжить прочитать и отбросить остальную часть запроса. Не должно выполнять запрошенный метод, если он возвращает конечный код состояния.

Это звучит для меня, как мне нужно сделать два ответы на запрос, т. е. он должен немедленно отправить ответ http 100 Continue, а затем продолжить чтение из исходного потока запросов (т. е. HttpContext.Request.InputStream) без завершения запроса, а затем, наконец, отправки результирующего кода состояния (для аргумента, скажем, что это 204 нет результата контента).

Итак, вопросы:

  1. правильно ли я читаю спецификацию, что мне нужно сделать два ответа на запрос?
  2. как это может быть сделано в ASP.NET MVC?

w.r.т. (2) я попытался использовать следующий код, прежде чем продолжить чтение входного потока...

HttpContext.Response.StatusCode = 100;
HttpContext.Response.Flush();
HttpContext.Response.Clear();

...но когда я пытаюсь установить окончательный код состояния 204 я получаю ошибку:

система.Сеть.HttpException: сервер не может установить статус после отправки заголовков HTTP.

12
asp.net-mvc http http-headers http-status-code-100

3 ответов

100-ПРОДОЛЖИТЬ должно обрабатываться IIS. Есть ли причина, по которой вы хотите сделать это явно?

2

.NET framework по умолчанию всегда отправляет expect: 100-continue заголовок для каждого сообщения HTTP 1.1. Это поведение можно программно контролировать по запросу через System.Net.ServicePoint.Expect100Continue свойства вот так:

HttpWebRequest httpReq = GetHttpWebRequestForPost();
httpReq.ServicePoint.Expect100Continue = false;

его можно также глобально контролировать программно:

System.Net.ServicePointManager.Expect100Continue = false;

...или глобально через настройки:

<system.net>
  <settings>
    <servicePointManager expect100Continue="false"/>
  </settings>
</system.net>

спасибо Лэнс Олсон и Фила Хаака для этого информация.

15

IIS обрабатывает 100.

Что сказал, Нет, это не два ответа. В HTTP, когда Expect: 100-continue входит как часть заголовков сообщений, клиент должен ждать, пока он не получит ответ перед отправкой содержимого.

из-за пути asp.net имеет архитектуру, у вас мало контроля над выходным потоком. Любые данные, которые записываются в поток, автоматически помещаются в ответ 200 с фрагментированной кодировкой при каждом сбросе, будь то ты в буферном режиме или нет.

к сожалению, все это скрыто во внутренних методах повсюду, и в результате, если вы полагаетесь на asp.net, как и MVC, вы в значительной степени не можете обойти его.

подождите, пока вы не попытаетесь получить доступ к входному потоку не буферизованным способом. Весь груз боли.

Seb

2