2009-05-18 12 views
10

Sto implementando un'API REST utilizzando ASP.NET MVC e un piccolo ostacolo è arrivato sotto forma dell'intestazione della richiesta Expect: 100-continue per le richieste con un corpo postale.Supporto dell'intestazione "Expect: 100-continue" con ASP.NET MVC

RFC 2616 afferma che:

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.

Questo suona per me come ho bisogno di fare due risposte alla richiesta, vale a dire che deve inviare immediatamente un HTTP 100 Continue risposta, e poi continuare a leggere dalla flusso di richiesta originale (ovvero HttpContext.Request.InputStream) senza terminare la richiesta, quindi inviare il codice di stato risultante (per ragioni di discussione, diciamo che è un risultato 204 senza contenuto).

Quindi, le domande sono:

  1. Sto leggendo le specifiche destra, che ho bisogno di fare due risposte ad una richiesta?
  2. Come può essere fatto in ASP.NET MVC?

w.r.t. (2) Ho provato con il seguente codice prima di procedere alla lettura del flusso di input ...

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

... ma quando provo a impostare il codice 204 di stato finale ottengo l'errore:

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

risposta

2

100-continue deve essere gestito da IIS. C'è una ragione per cui vuoi farlo esplicitamente? gestisce

+0

No, mi piacerebbe evitarlo! Non avevo realizzato che IIS lo avrebbe gestito senza alcun intervento. –

+0

Ho riscontrato un errore in 'WebRequest' con 100 Continua. Questa è una buona ragione per non usarla. http://regis.decamps.info/blog/2010/12/c-bug-in-webrequest/ – rds

2

IIS 100.

Detto questo, no non è due risposte. In HTTP, quando l'Expect: 100-continue arriva come parte delle intestazioni del messaggio, il client deve essere in attesa fino a quando non riceve la risposta prima di inviare il contenuto.

A causa del modo in cui è progettato l'asp.net, si ha un controllo limitato sul flusso di output. Qualsiasi dato che viene scritto nel flusso viene automaticamente inserito in una risposta di 200 con codifica Chunked ogni volta che si esegue il flush, che sia in modalità buffer o meno.

Purtroppo tutto questo materiale è nascosto nei metodi interni dappertutto, e il risultato è che se si fa affidamento su asp.net, come su MVC, non si è in grado di bypassarlo.

Attendi fino a quando non provi ad accedere al flusso di input in modo non bufferizzato. Un intero carico di dolore.

Seb

15

Il framework .NET di default invia sempre l'intestazione expect: 100-continue per ogni HTTP 1.1 successivo. Questo comportamento può essere controllato programmazione per richiesta tramite la proprietà System.Net.ServicePoint.Expect100Continue modo:

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

Può anche essere controllato globalmente programmazione:

...o globalmente attraverso la configurazione:

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

Grazie Lance Olson e Phil Haack per queste informazioni.

+0

dove dovrei aggiungere System.Net.ServicePointManager.Expect100Continue = false; nel mio codice wp7? – Apoorva

+1

Non ho ancora programmato alcun programma per WP7, ma immagino che il codice vada in App.xaml.cs, possibilmente nel gestore di eventi Application_Launching o Application_Activated. –

+0

Questo non risponde affatto alla domanda ... –