Supporting the "Expect: 100-continue" header with ASP.NET MVC

Question

I'm implementing a REST API using ASP.NET MVC, and a little stumbling block has come up in the form of the Expect: 100-continue request header for requests with a post body.

RFC 2616 states that:

Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code. The origin server MUST NOT wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it MAY close the transport connection or it MAY continue to read and discard the rest of the request. It MUST NOT perform the requested method if it returns a final status code.

This sounds to me like I need to make two responses to the request, i.e. it needs to immediately send a HTTP 100 Continue response, and then continue reading from the original request stream (i.e. HttpContext.Request.InputStream) without ending the request, and then finally sending the resultant status code (for the sake of argument, lets say it's a 204 No Content result).

So, questions are:

1. Am I reading the specification right, that I need to make two responses to a request?
2. How can this be done in ASP.NET MVC?

w.r.t. (2) I have tried using the following code before proceeding 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 HTTP headers have been sent.

Pren

Answer 1

100-continue should be handled by IIS. Is there a reason why you want to do this explicitly?

Optical

No - i'd like to avoid it! I didn't realise IIS would handle it without any intervention. – Pren

I have encountered a bug in WebRequestwith 100 Continue. That's a good reason not to use it. regis.decamps.info/blog/2010/12/c-bug-in-webrequest – Viscountess

Answer 2

The .NET framework by default always sends the expect: 100-continue header for every HTTP 1.1 post. This behavior can be programmatically controlled per request via the System.Net.ServicePoint.Expect100Continue property like so:

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

It can also be globally controlled programmatically:

System.Net.ServicePointManager.Expect100Continue = false;

...or globally through configuration:

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

Thank you Lance Olson and Phil Haack for this info.

Faustena

where should i add System.Net.ServicePointManager.Expect100Continue = false; in my wp7 code? – Hassett

I haven't done any programming for WP7, but I would imagine the code would go in App.xaml.cs, possibly in the Application_Launching or Application_Activated event handler. – Faustena

The OP is talking about sending Response from the Server to Client which has made a POST Request. But you are talking about making Request to some resource on a Server from a client. This is totally unrelated. – Cerebrovascular

@Vipresh, you're right. I submitted the answer years ago when I was having a problem with the header on requests I was making. I guess I jumped the gun not fully understanding the OP's problem. Regardless, it seems like the answer has helped some people. What do you suggest we do? – Faustena

@Jhon Berberich you are right there's a help full link in the answer , which may have helped many people the up votes on the answer says that. I will see if I can revert my down vote , I did it as I was facing the same problem as the OP and had already seen the link you posted so I thought it added noise. – Cerebrovascular

In my case, something changed in the environments (we suspect a windows update, because there was no changes to the environments) that made a web service that was working to start to give the 417 error due to the 100 Continue Header. What saved the day was the configuration way in the web.config: <servicePointManager expect100Continue="false"/> – Transponder

Answer 3

IIS handles the 100.

That said, no it's not two responses. In HTTP, when the Expect: 100-continue comes in as part of the message headers, the client should be waiting until it receives the response before sending the content.

Because of the way asp.net is architected, you have little control over the output stream. Any data that gets written to the stream is automatically put in a 200 response with chunked encoding whenever you flush, be it that you're in buffered mode or not.

Sadly all this stuff is hidden away in internal methods all over the place, and the result is that if you rely on asp.net, as does MVC, you're pretty much unable to bypass it.

Wait till you try and access the input stream in a non-buffered way. A whole load of pain.

Seb

Erikerika