BrowserHttpMessageHandler reads body content to end

[csnewman]

Inside "Blazor/src/Microsoft.AspNetCore.Blazor.Browser.JS/src/Services/Http.ts", the response data is handled via " responseData = await response.arrayBuffer();", which reads the entire response stream to the end, and then returns the data, however this is the incorrect behaviour.

HttpMessageHandler's should not buffer the response as this is handled within the HttpClient.

This means that method such as "_httpClient.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, CancellationToken.None);", are not handled correctly as the ResponseHeadersRead flag is not respected, due to the content body being read to the end.

We would need to wrap the ReadableStream from the JS side to the c# side as the HttpContent in the ReceiveResponse in BrowserHttpMessageHandler.

Is there any chance of getting this fixed? As I've managed to get the c# signalr client working with long polling, but can't get the "ServerSentEventsTransport" to work until this is fixed, as otherwise the client timeouts trying to read the content body to the end, when it shouldn't as the ResponseHeadersRead is passed.

[Suchiman]

I have considered implementing Streaming responses but last time i've looked at it, it was and still is considered experimental https://developer.mozilla.org/en-US/docs/Web/API/Body/body#Browser_compatibility and not supported everywhere.
Aside from that, this should be doable i think.

[csnewman]

There are some polyfills available for the streams api, however even without these polyfills, being able to detect and use the correct behaviour when available would be a massive set forward.

For me in my use case, if the browser doesn't support the streams api, I would just disable the server events transport in signalr, and fallback to long polling.

[danroth27]

Thanks for reporting this issue!

I've managed to get the c# signalr client working with long polling

Is you're main goal here to get a working SignalR client? Have you looked at https://github.com/BlazorExtensions/SignalR?

[csnewman]

Yeah, thanks for the suggestion, but I'm working on using the .Net client within Blazor, instead of that wrapped api version.

You can take a look if you want? https://github.com/csnewman/BlazorSignalR, Currently only long polling works.

This approach has the benefit of it just being an addon for the actual .net api, and having all the relevant docs available and supporting all future versions (provided the underlying transport mechanics stay the same). I'll probably end up just implementing the websocket and serversentevent transport in typescript, and proxying those.

[danroth27]

Got it - makes sense.

[Suchiman]

@csnewman i've opened #1387 which makes ResponseHeadersRead work to allow reading headers without reading the body. Does that fix your issue or do you also strictly require that the response body gets streamed as well?

[csnewman]

@Suchiman the response body must be streamed for server side events, as the connection is kept open forever, and messages are wrote to the body as available, meaning the body can never be fully read, it must be streamed.

Thanks for creating that fix though, and I imagine it will fix some simpler use cases, however fixing message handler is the only real solution.

[csnewman]

@Suchiman There's no rush on fixing this, as I have worked around the lack of support by just proxying the requests across to JS and using the browsers mechanisms (like EventSource).