Unterstützen die "Expect: 100-continue" -Header mit ASP.NET MVC

Question

Ich implementiere eine REST-API mit ASP.NET MVC, und ein kleines Stolperstein ist in der Form der Expect: 100-continue Anfrage Header für Anfragen mit ein Postkörper.

RFC 2616 besagt, dass:

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.

Das klingt für mich wie ich zwei Antworten auf die Anfrage machen muß, also muss es sofort ein HTTP-100-Antwort weiter senden, und dann weiter von der Lese Original-Anfrage-Stream (zB HttpContext.Request.InputStream) ohne die Anfrage zu beenden, und dann den resultierenden Status-Code zu senden (aus Gründen des Arguments, sagen wir, es ist ein 204 Kein Inhalt-Ergebnis). So

, Fragen sind:

1. Bin ich die Spezifikation richtig zu lesen, dass ich zwei Antworten auf eine Anfrage machen müssen?
2. Wie kann dies in ASP.NET MVC getan werden?

w.r.t. (2) Ich habe versucht, den folgenden Code verwenden, bevor Sie fortfahren den Eingangsstrom zu lesen ...

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

... aber wenn ich versuche, die endgültige 204-Statuscode zu setzen erhalte ich die Fehlermeldung:

System.Web.HttpException: Server cannot set status after HTTP headers have been sent.

Answer 1

100-continue sollte von IIS behandelt werden. Gibt es einen Grund, warum Sie das explizit machen wollen?

Answer 2

IIS behandelt das 100.

Das heißt, nein, es nicht zwei Antworten ist. Wenn in HTTP das Expect: 100-continue als Teil der Nachrichtenheader eingeht, sollte der Client warten, bis er die Antwort erhält, bevor er den Inhalt sendet.

Aufgrund der Architektur von asp.net haben Sie wenig Kontrolle über den Ausgabestrom. Alle Daten, die in den Stream geschrieben werden, werden automatisch in eine 200-Response mit Chunked-Encoding eingefügt, wenn Sie sie leeren, sei es im gepufferten Modus oder nicht.

Leider ist all das Zeug in internen Methoden überall versteckt, und das Ergebnis ist, dass, wenn Sie sich auf asp.net verlassen, wie MVC, Sie es kaum umgehen können.

Warten Sie, bis Sie versuchen, auf den Eingabestrom auf nicht gepufferte Weise zuzugreifen. Eine ganze Ladung Schmerz.

Seb

Answer 3

Die .NET-Framework standardmäßig sendet immer die expect: 100-continue Header für jeden HTTP 1.1 nach. Dieses Verhalten kann programmatisch pro Anfrage wie so über die System.Net.ServicePoint.Expect100Continue Eigenschaft gesteuert werden:

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

auch global programmatisch gesteuert werden Es kann:

...oder global durch Konfiguration:

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

Danke Lance Olson und Phil Haack für diese Info.