ASP.NET-Web-API Protokollieren eingehender Anforderungsinhalte

9

Ich versuche, den Web-API-Anforderungsinhalt abzumelden - d. h. die JSON-Zeichenfolge. Ich habe eine ITraceWriter-Klasse implementiert ( Beispiel ) und es so konfiguriert, dass die Web-API es in der Pipeline aufruft. Aber wenn ich die request.Content lesen oder in einen Stream kopieren, um es zu lesen, ist für die Methode nicht verfügbar, was zu einem Nullmodell führt. Dieser Beitrag spricht über dieses Problem ein bisschen. Jeder hat Erfahrung beim Abmelden eingehender Web-API-Anfrage-Inhalte und weiß, was der beste Ansatz ist?

Danke

Aktualisieren Sie A

Ich habe ein einfaches Beispiel-Web-API-Projekt erstellt, um alles in meinem Projekt auszuschließen, und ich sehe immer noch, dass das Modell wegen der Protokollierung null ist. Ich teste einfach ein paar Mal hintereinander, indem ich über Fidder poste und sehe, dass mein Modell in null kommt. Wenn die Breakpoints an Ort und Stelle sind, könnte es funktionieren, weshalb ich denke, dass es ein Sync / Timing-Problem gibt. Irgendwelche Gedanken, wie man das zur Arbeit bringt?

Kopfzeile:

%Vor%

Körper:

%Vor%

Hier ist der Code:

Controller:

%Vor%

Modell:

%Vor%

Logger:

%Vor%

Logger in der WebApiConfig-Klasse verbinden:

%Vor%

Aktualisieren Sie B

Es sieht so aus, als würde es jetzt funktionieren, wenn ich den Logger in den folgenden Code ändere, indem ich das awarn, async hinzufüge und das Ergebnis zurücksende. Scheint etwas, das ich im asynchronen Code oder wirklich ein Timing-Problem oder etwas nicht verstehe.

%Vor%     
Bryan 19.03.2013, 19:34
quelle

1 Antwort

5

Wie Filip in diesem Post erwähnt, packen ReadAsStringAsync- oder ReadAsByteArrayAsync-Methoden den Anforderungsinhalt intern. Dies bedeutet, dass Sie selbst dann, wenn der Stream-Typ Ihrer eingehenden Anfrage ein nicht gepufferter Stream ist, problemlos ein ReadAsStringAsync / ReadAsByteArrayAsync an einem Message-Handler ausführen können und auch erwarten, dass die Modellbindung funktioniert.

Standardmäßig wird der Stream einer Anfrage sowohl in Webhost- als auch in Selfhost-Fällen gepuffert. Wenn Sie jedoch überprüfen möchten, ob ReadAsStringAsync / ReadAsByteArrayAsync und das Modellbidding auch im nicht gepufferten Modus funktionieren, können Sie den nicht gepufferten Modus erzwingen:

%Vor%

Nur zur Info ... der obige Richtlinien-Selektor funktioniert nur für den Web-Host. Wenn Sie einen ähnlichen Test in SelfHost durchführen möchten, gehen Sie folgendermaßen vor:

%Vor%

Nach Update B des Posts oben:

Sie können Ihren Handler wie folgt ändern:

%Vor%     
Kiran Challa 19.03.2013, 20:31
quelle

Tags und Links