Wie lese ich den Anforderungshauptteil in einem asp.net-Kern-Webapi-Controller?

Ich versuche, den Anfragetext in der OnActionExecutingMethode zu lesen , aber ich bekomme immer nullfür den Text.

var request = context.HttpContext.Request;
var stream = new StreamReader(request.Body);
var body = stream.ReadToEnd();

Ich habe versucht, die Stream-Position explizit auf 0 zu setzen, aber das hat auch nicht funktioniert. Da dies ASP.NET CORE ist, sind die Dinge meiner Meinung nach etwas anders. Ich kann alle Beispiele hier sehen, die sich auf alte Webapi-Versionen beziehen.
Gibt es eine andere Möglichkeit, dies zu tun?

In ASP.Net Core scheint es kompliziert zu sein, die Textanforderung mehrmals zu lesen. Wenn Ihr erster Versuch es jedoch richtig macht, sollten Sie für die nächsten Versuche in Ordnung sein.

Ich habe mehrere Turnarounds gelesen, indem ich zum Beispiel den Body Stream ersetzt habe, aber ich denke, das Folgende ist das sauberste:

Die wichtigsten Punkte sind

1. um die Anfrage wissen zu lassen, dass Sie ihren Körper zweimal oder mehrmals lesen werden,
2. den Körperstrom nicht zu schließen, und
3. um es in seine Ausgangsposition zurückzuspulen, damit der interne Prozess nicht verloren geht.

[BEARBEITEN]

Wie von Murad hervorgehoben, können Sie auch die Erweiterung .Net Core 2.1 nutzen: EnableBufferingSie speichert große Anforderungen auf der Festplatte, anstatt sie im Speicher zu belassen, und vermeidet Probleme mit großen Streams, die im Speicher gespeichert sind (Dateien, Bilder, ...). . Sie können den temporären Ordner ändern, indem Sie die ASPNETCORE_TEMPUmgebungsvariable festlegen. Die Dateien werden gelöscht, sobald die Anforderung beendet ist.

In einem AuthorizationFilter können Sie Folgendes tun:

// Helper to enable request stream rewinds
using Microsoft.AspNetCore.Http.Internal;
[...]
public class EnableBodyRewind : Attribute, IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var bodyStr = "";
        var req = context.HttpContext.Request;

        // Allows using several time the stream in ASP.Net Core
        req.EnableRewind(); 

        // Arguments: Stream, Encoding, detect encoding, buffer size 
        // AND, the most important: keep stream opened
        using (StreamReader reader 
                  = new StreamReader(req.Body, Encoding.UTF8, true, 1024, true))
        {
            bodyStr = reader.ReadToEnd();
        }

        // Rewind, so the core is not lost when it looks the body for the request
        req.Body.Position = 0;

        // Do whatever work with bodyStr here

    }
}



public class SomeController : Controller
{
    [HttpPost("MyRoute")]
    [EnableBodyRewind]
    public IActionResult SomeAction([FromBody]MyPostModel model )
    {
        // play the body string again
    }
}

Anschließend können Sie den Body im Request-Handler erneut verwenden.

Wenn Sie in Ihrem Fall ein Nullergebnis erhalten, bedeutet dies wahrscheinlich, dass der Körper bereits zu einem früheren Zeitpunkt gelesen wurde. In diesem Fall müssen Sie möglicherweise eine Middleware verwenden (siehe unten).

Seien Sie jedoch vorsichtig, wenn Sie mit großen Streams umgehen. Dieses Verhalten impliziert, dass alles in den Speicher geladen wird. Dies sollte bei einem Datei-Upload nicht ausgelöst werden.

Möglicherweise möchten Sie dies als Middleware verwenden

Meins sieht folgendermaßen aus (wenn Sie große Dateien herunterladen / hochladen, sollte dies deaktiviert werden, um Speicherprobleme zu vermeiden):

public sealed class BodyRewindMiddleware
{
    private readonly RequestDelegate _next;

    public BodyRewindMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try { context.Request.EnableRewind(); } catch { }
        await _next(context);
        // context.Request.Body.Dipose() might be added to release memory, not tested
    }
}
public static class BodyRewindExtensions
{
    public static IApplicationBuilder EnableRequestBodyRewind(this IApplicationBuilder app)
    {
        if (app == null)
        {
            throw new ArgumentNullException(nameof(app));
        }

        return app.UseMiddleware<BodyRewindMiddleware>();
    }

}

Eine klarere Lösung funktioniert in ASP.Net Core 2.1 / 3.1

Filterklasse

using Microsoft.AspNetCore.Authorization;
// For ASP.NET 2.1
using Microsoft.AspNetCore.Http.Internal;
// For ASP.NET 3.1
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc.Filters;

public class ReadableBodyStreamAttribute : AuthorizeAttribute, IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        // For ASP.NET 2.1
        // context.HttpContext.Request.EnableRewind();
        // For ASP.NET 3.1
        // context.HttpContext.Request.EnableBuffering();
    }
}

In einem Controller

[HttpPost]
[ReadableBodyStream]
public string SomePostMethod()
{
    //Note: if you're late and body has already been read, you may need this next line
    //Note2: if "Note" is true and Body was read using StreamReader too, then it may be necessary to set "leaveOpen: true" for that stream.
    HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);

    using (StreamReader stream = new StreamReader(HttpContext.Request.Body))
    {
        string body = stream.ReadToEnd();
        // body = "param=somevalue&param2=someothervalue"
    }
}

Um den Anfragetext zurückspulen zu können, hat mir die Antwort von @ Jean geholfen, eine Lösung zu finden, die anscheinend gut funktioniert. Ich verwende dies derzeit für Global Exception Handler Middleware, aber das Prinzip ist das gleiche.

Ich habe eine Middleware erstellt, die im Grunde das Zurückspulen auf dem Anforderungshauptteil ermöglicht (anstelle eines Dekorateurs).

using Microsoft.AspNetCore.Http.Internal;
[...]
public class EnableRequestRewindMiddleware
{
    private readonly RequestDelegate _next;

    public EnableRequestRewindMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        context.Request.EnableRewind();
        await _next(context);
    }
}

public static class EnableRequestRewindExtension
{
    public static IApplicationBuilder UseEnableRequestRewind(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<EnableRequestRewindMiddleware>();
    }
}

Dies kann dann Startup.cswie folgt verwendet werden:

[...]
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    [...]
    app.UseEnableRequestRewind();
    [...]
}

Mit diesem Ansatz konnte ich den Anforderungskörperstrom erfolgreich zurückspulen.

Dies ist ein bisschen wie ein alter Thread, aber seit ich hier bin, dachte ich, ich würde meine Ergebnisse veröffentlichen, damit sie anderen helfen können.

Erstens hatte ich das gleiche Problem, bei dem ich den Request.Body abrufen und etwas damit anfangen wollte (Protokollierung / Überwachung). Ansonsten wollte ich, dass der Endpunkt gleich aussieht.

Es schien also, als würde der Aufruf von EnableBuffering () den Trick machen. Dann können Sie eine Suche (0, xxx) am Körper durchführen und den Inhalt usw. erneut lesen.

Dies führte jedoch zu meiner nächsten Ausgabe. Beim Zugriff auf den Endpunkt werden Ausnahmen "Synchornous-Operationen sind nicht zulässig" angezeigt. Die Problemumgehung besteht darin, die Eigenschaft AllowSynchronousIO = true in den Optionen festzulegen. Es gibt eine Reihe von Möglichkeiten, um dies zu erreichen (aber nicht wichtig, um hier näher darauf einzugehen ..)

DANN ist das nächste Problem, dass, wenn ich die Anfrage lese, sie bereits entsorgt wurde. Pfui. Also, was gibt es?

Ich verwende Newtonsoft.JSON als meinen [FromBody] -Parser im Endpiont-Aufruf. Das ist es, was für die synchronen Lesevorgänge verantwortlich ist und es schließt auch den Stream, wenn es fertig ist. Lösung? Lesen Sie den Stream, bevor er zum JSON-Parsing gelangt? Klar, das funktioniert und ich bin dazu gekommen:

 /// <summary>
/// quick and dirty middleware that enables buffering the request body
/// </summary>
/// <remarks>
/// this allows us to re-read the request body's inputstream so that we can capture the original request as is
/// </remarks>
public class ReadRequestBodyIntoItemsAttribute : AuthorizeAttribute, IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationFilterContext context)
    {
        if (context == null) return;

        // NEW! enable sync IO beacuse the JSON reader apparently doesn't use async and it throws an exception otherwise
        var syncIOFeature = context.HttpContext.Features.Get<IHttpBodyControlFeature>();
        if (syncIOFeature != null)
        {
            syncIOFeature.AllowSynchronousIO = true;

            var req = context.HttpContext.Request;

            req.EnableBuffering();

            // read the body here as a workarond for the JSON parser disposing the stream
            if (req.Body.CanSeek)
            {
                req.Body.Seek(0, SeekOrigin.Begin);

                // if body (stream) can seek, we can read the body to a string for logging purposes
                using (var reader = new StreamReader(
                     req.Body,
                     encoding: Encoding.UTF8,
                     detectEncodingFromByteOrderMarks: false,
                     bufferSize: 8192,
                     leaveOpen: true))
                {
                    var jsonString = reader.ReadToEnd();

                    // store into the HTTP context Items["request_body"]
                    context.HttpContext.Items.Add("request_body", jsonString);
                }

                // go back to beginning so json reader get's the whole thing
                req.Body.Seek(0, SeekOrigin.Begin);
            }
        }
    }
}

Jetzt kann ich mit HttpContext.Items ["request_body"] in den Endpunkten mit dem Attribut [ReadRequestBodyIntoItems] auf den Body zugreifen.

Aber Mann, das scheint viel zu viele Reifen zu sein, um durch zu springen. Hier habe ich also geendet und bin sehr zufrieden damit.

Mein Endpunkt begann wie folgt:

[HttpPost("")]
[ReadRequestBodyIntoItems]
[Consumes("application/json")]
public async Task<IActionResult> ReceiveSomeData([FromBody] MyJsonObjectType value)
{
    val bodyString = HttpContext.Items["request_body"];
    // use the body, process the stuff...
}

Es ist jedoch viel einfacher, die Signatur wie folgt zu ändern:

[HttpPost("")]
[Consumes("application/json")]
public async Task<IActionResult> ReceiveSomeData()
{
    using (var reader = new StreamReader(
           Request.Body,
           encoding: Encoding.UTF8,
           detectEncodingFromByteOrderMarks: false
    ))
    {
        var bodyString = await reader.ReadToEndAsync();

        var value = JsonConvert.DeserializeObject<MyJsonObjectType>(bodyString);

        // use the body, process the stuff...
    }
}

Das hat mir sehr gut gefallen, weil es den Körperstrom nur einmal liest und ich die Kontrolle über die Deserialisierung habe. Sicher, es ist schön, wenn der ASP.NET-Kern diese Magie für mich ausführt, aber hier verschwende ich keine Zeit damit, den Stream zweimal zu lesen (möglicherweise jedes Mal zu puffern), und der Code ist ziemlich klar und sauber.

Wenn Sie diese Funktionalität auf vielen Endpunkten benötigen, sind die Middleware-Ansätze möglicherweise sauberer, oder Sie können die Körperextraktion zumindest in eine Erweiterungsfunktion einkapseln, um den Code präziser zu gestalten.

Wie auch immer, ich habe keine Quelle gefunden, die alle drei Aspekte dieser Ausgabe berührt hat, daher dieser Beitrag. Hoffentlich hilft das jemandem!

Übrigens: Dies war mit ASP .NET Core 3.1.

Ich hatte ein ähnliches Problem bei der Verwendung von ASP.NET Core 2.1:

• Ich benötige eine benutzerdefinierte Middleware, um die POST-Daten zu lesen und einige Sicherheitsüberprüfungen durchzuführen
• Die Verwendung eines Autorisierungsfilters ist aufgrund der großen Anzahl betroffener Aktionen nicht praktikabel
• Ich muss zulassen, dass Objekte in den Aktionen gebunden werden ([FromBody] someObject). Vielen Dank SaoBizfür den Hinweis auf diese Lösung.

Die naheliegende Lösung besteht also darin, das Zurückspulen der Anforderung zuzulassen. Stellen Sie jedoch sicher, dass die Bindung nach dem Lesen des Körpers weiterhin funktioniert.

EnableRequestRewindMiddleware

public class EnableRequestRewindMiddleware
{
    private readonly RequestDelegate _next;

    ///<inheritdoc/>
    public EnableRequestRewindMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="context"></param>
    /// <returns></returns>
    public async Task Invoke(HttpContext context)
    {
        context.Request.EnableRewind();
        await _next(context);
    }
}

Startup.cs

(Platzieren Sie dies am Anfang der Configure-Methode.)

app.UseMiddleware<EnableRequestRewindMiddleware>();

Eine andere Middleware

Dies ist Teil der Middleware, die das Entpacken der POST-Informationen zum Überprüfen von Daten erfordert.

using (var stream = new MemoryStream())
{
    // make sure that body is read from the beginning
    context.Request.Body.Seek(0, SeekOrigin.Begin);
    context.Request.Body.CopyTo(stream);
    string requestBody = Encoding.UTF8.GetString(stream.ToArray());

    // this is required, otherwise model binding will return null
    context.Request.Body.Seek(0, SeekOrigin.Begin);
}

Die IHttpContextAccessorMethode funktioniert, wenn Sie diesen Weg gehen möchten.

TLDR;

• Injizieren Sie die IHttpContextAccessor

• Rücklauf - HttpContextAccessor.HttpContext.Request.Body.Seek(0, System.IO.SeekOrigin.Begin);

• Lesen -- System.IO.StreamReader sr = new System.IO.StreamReader(HttpContextAccessor.HttpContext.Request.Body); JObject asObj = JObject.Parse(sr.ReadToEnd());

Mehr - Ein Versuch, ein präzises, nicht kompiliertes Beispiel für die Elemente zu erstellen, die Sie sicherstellen müssen, damit sie verwendet werden können IHttpContextAccessor. Die Antworten haben richtig darauf hingewiesen, dass Sie zum Versuch zurückkehren müssen, den Anfragetext zu lesen. Die CanSeek, PositionEigenschaften auf der Anfrage Körper strömen hilfreich dies für die Überprüfung.

.NET Core DI-Dokumente

// First -- Make the accessor DI available
//
// Add an IHttpContextAccessor to your ConfigureServices method, found by default
// in your Startup.cs file:
// Extraneous junk removed for some brevity:
public void ConfigureServices(IServiceCollection services)
{
    // Typical items found in ConfigureServices:
    services.AddMvc(config => { config.Filters.Add(typeof(ExceptionFilterAttribute)); });
    // ...

    // Add or ensure that an IHttpContextAccessor is available within your Dependency Injection container
    services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
}

// Second -- Inject the accessor
//
// Elsewhere in the constructor of a class in which you want
// to access the incoming Http request, typically 
// in a controller class of yours:
public class MyResourceController : Controller
{
    public ILogger<PricesController> Logger { get; }
    public IHttpContextAccessor HttpContextAccessor { get; }

    public CommandController(
        ILogger<CommandController> logger,
        IHttpContextAccessor httpContextAccessor)
    {
        Logger = logger;
        HttpContextAccessor = httpContextAccessor;
    }

    // ...

    // Lastly -- a typical use 
    [Route("command/resource-a/{id}")]
    [HttpPut]
    public ObjectResult PutUpdate([FromRoute] string id, [FromBody] ModelObject requestModel)
    {
        if (HttpContextAccessor.HttpContext.Request.Body.CanSeek)
        {
            HttpContextAccessor.HttpContext.Request.Body.Seek(0, System.IO.SeekOrigin.Begin);
            System.IO.StreamReader sr = new System.IO.StreamReader(HttpContextAccessor.HttpContext.Request.Body);
            JObject asObj = JObject.Parse(sr.ReadToEnd());

            var keyVal = asObj.ContainsKey("key-a");
        }
    }
}    

Ich konnte den Anforderungshauptteil in einer asp.net Core 3.1-Anwendung wie dieser lesen (zusammen mit einer einfachen Middleware, die das Puffern ermöglicht - das Aktivieren des Zurückspulens scheint für frühere .Net Core-Versionen zu funktionieren-):

var reader = await Request.BodyReader.ReadAsync();
Request.Body.Position = 0;
var buffer = reader.Buffer;
var body = Encoding.UTF8.GetString(buffer.FirstSpan);
Request.Body.Position = 0;

Kürzlich bin ich auf eine sehr elegante Lösung gestoßen, die zufälliges JSON berücksichtigt, von dem Sie keine Ahnung haben, wie es aufgebaut ist:

    [HttpPost]
    public JsonResult Test([FromBody] JsonElement json)
    {
        return Json(json);
    }

So einfach ist das.

Zum Lesen Bodykönnen Sie asynchron lesen.

Verwenden Sie die asyncMethode wie folgt:

public async Task<IActionResult> GetBody()
{
      string body="";
      using (StreamReader stream = new StreamReader(Request.Body))
      {
           body = await stream.ReadToEndAsync();
      }
    return Json(body);
}

Test mit Postbote:

Es funktioniert gut und wurde in der Asp.net coreVersion getestet 2.0 , 2.1 , 2.2, 3.0.

Ich hoffe es ist nützlich.

Ich wollte auch den Request.Body lesen, ohne ihn automatisch einem Aktionsparameter-Modell zuzuordnen. Viele verschiedene Möglichkeiten getestet, bevor dies gelöst wurde. Und ich habe keine hier beschriebene funktionierende Lösung gefunden. Diese Lösung basiert derzeit auf dem .NET Core 3.0-Framework.

reader.readToEnd () wurde auf einfache Weise gesäumt, obwohl es kompiliert wurde, löste es eine Laufzeitausnahme aus, bei der ich einen asynchronen Aufruf verwenden musste. Also habe ich stattdessen ReadToEndAsync () verwendet, aber es hat manchmal funktioniert und manchmal nicht. Gib mir Fehler wie, kann nicht lesen, nachdem der Stream geschlossen wurde. Das Problem ist, dass wir nicht garantieren können, dass das Ergebnis im selben Thread zurückgegeben wird (selbst wenn wir das Warten verwenden). Wir brauchen also eine Art Rückruf. Diese Lösung hat bei mir funktioniert.

[Route("[controller]/[action]")]
public class MyController : ControllerBase
{

    // ...

    [HttpPost]
    public async void TheAction()
    {
        try
        {
            HttpContext.Request.EnableBuffering();
            Request.Body.Position = 0;
            using (StreamReader stream = new StreamReader(HttpContext.Request.Body))
            {
                var task = stream
                    .ReadToEndAsync()
                    .ContinueWith(t => {
                        var res = t.Result;
                        // TODO: Handle the post result!
                    });

                // await processing of the result
                task.Wait();
            }
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to handle post!");
        }
    }

Der einfachste Weg, dies zu tun, ist der folgende:

1. Fügen Sie in der Controller-Methode, aus der Sie den Body extrahieren müssen, diesen Parameter hinzu: [FromBody] SomeClass-Wert

2. Deklarieren Sie die "SomeClass" als: class SomeClass {public string SomeParameter {get; einstellen; }}

Wenn der Rohkörper als JSON gesendet wird, kann der .net-Kern ihn sehr einfach lesen.

Für diejenigen, die einfach den Inhalt (Anfragetext) aus der Anfrage erhalten möchten:

Verwenden Sie das [FromBody]Attribut in Ihrem Controller-Methodenparameter.

[Route("api/mytest")]
[ApiController]
public class MyTestController : Controller
{
    [HttpPost]
    [Route("content")]
    public async Task<string> ReceiveContent([FromBody] string content)
    {
        // Do work with content
    }
}

Wie doc sagt: Dieses Attribut gibt an, dass ein Parameter oder eine Eigenschaft mithilfe des Anforderungshauptteils gebunden werden soll.

Eine schnelle Möglichkeit, die Antwortpufferung in .NET Core 3.1 hinzuzufügen, ist

    app.Use((context, next) =>
    {
        context.Request.EnableBuffering();
        return next();
    });

in Startup.cs. Ich fand, dass dies auch garantiert, dass die Pufferung aktiviert wird, bevor der Stream gelesen wurde, was ein Problem für .Net Core 3.1 mit einigen der anderen Antworten auf Middleware- / Autorisierungsfilter war, die ich gesehen habe.

Dann können Sie Ihren Anfragetext über HttpContext.Request.Bodyin Ihrem Handler lesen, wie mehrere andere vorgeschlagen haben.

Erwägenswert ist auch, dass EnableBufferinges Überladungen gibt, mit denen Sie die Pufferung im Speicher begrenzen können, bevor eine temporäre Datei verwendet wird, sowie eine Gesamtbeschränkung für Ihren Puffer. Hinweis: Wenn eine Anforderung dieses Limit überschreitet, wird eine Ausnahme ausgelöst und die Anforderung erreicht niemals Ihren Handler.