Support for "Expect: 100-Continue" header with ASP.NET MVC
I am implementing a REST API using ASP.NET MVC and a little stumbling block came in the form of a request header Expect: 100-continue
for requests with a message body.
RFC 2616 states that:
On receiving a request that includes a request header Expect field with an expectation of 100-continue, the origin server MUST either respond with a status of 100 (Continue) and continue reading from the input stream or respond with a final status code. the origin server MUST NOT wait for a request body before sending a 100 (Continue) response. If it replies with a final status code, it MAY close the transport connection or MAY continue to read and discard the rest of the request. This MUST NOT execute the requested method if it returns a final status code.
It seems to me that I need to make two responses per request, i.e. it should immediately send an HTTP 100 Continue response and then continue reading from the original request stream (i.e. HttpContext.Request.InputStream
) without aborting the request, and then finally sending the resulting status code (for argument's sake, let's say this is the result with no content).
So the questions:
- I am reading the right spec, what do I need to make two responses to a request?
- How do I do this in ASP.NET MVC?
wrt (2) I tried using the following code before continuing to read the input stream ...
HttpContext.Response.StatusCode = 100; HttpContext.Response.Flush(); HttpContext.Response.Clear();
... but when I try to set the final 204 status code, I get the error:
System.Web.HttpException: Server cannot set status after sending HTTP headers.
a source to share
The .NET framework, by default, always sends a header expect: 100-continue
for every HTTP 1.1 message. This behavior can be programmatically controlled on demand using the property System.Net.ServicePoint.Expect100Continue
:
HttpWebRequest httpReq = GetHttpWebRequestForPost();
httpReq.ServicePoint.Expect100Continue = false;
It can also be programmatically controlled globally:
System.Net.ServicePointManager.Expect100Continue = false;
... or globally via config:
<system.net>
<settings>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
Thanks to Lance Olson and Phil Haack for this information.
a source to share
IIS handles 100.
However, these are not two answers. In HTTP, when Expect: 100-continue comes in as part of the message headers, the client must wait until it receives a response before sending the content.
Because of the way asp.net is archived, you have little control over the output stream. Any data that is written to the stream is automatically put into an encoded 200 response whenever you hide, whether you are in buffered mode or not.
Unfortunately, all of these things are hidden in internal methods all over the place, and as a result you rely on asp.net, just like MVC you can hardly get around it.
Wait while you try to access the input stream in an unbuffered way. A whole load of pain.
Seb
a source to share