search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.48k stars 10.03k forks source link

Range requests do not work as expected #57070

Closed catmanjan closed 3 months ago

catmanjan commented 3 months ago

Is there an existing issue for this?

Describe the bug

I am trying to implement range requests as documented here https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests

Per the doco the first request should be a 200 with the following information:

HTTP/1.1 200 OK
…
Accept-Ranges: bytes
Content-Length: 146515

However, when I set Content-Length and return an Ok() response, I get an error:

System.InvalidOperationException: Response Content-Length mismatch: too few bytes written (0 of 2488340).

Expected Behavior

I should not be prevented from having a mismatch between the content-length header and any actual bytes sent.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

catmanjan commented 3 months ago

I've tracked the exception to here https://github.com/dotnet/aspnetcore/blob/27ae0821dded5d31b8f7a1cd4519a8ef3ccd6cc3/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L687

TBH this seems like a pretty big issue, doesn't this mean Kestrel streaming doesn't really work?

BrennanConroy commented 3 months ago

Did you send a HEAD request like the doc you linked to says? Because the very first thing the VerifyResponseContentLength method does is look for a HEAD request https://github.com/dotnet/aspnetcore/blob/27ae0821dded5d31b8f7a1cd4519a8ef3ccd6cc3/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L906

catmanjan commented 3 months ago

@BrennanConroy no, I am reproducing the issue with PDF.js (the OOTB Firefox PDF viewer) and it does not send a HEAD request - the docs say you can do a HEAD request, but it doesn't say you must. Other web server technologies (including IIS) allow the GET with non zero Content-Length and an empty response.

catmanjan commented 3 months ago

Here's an RFC I found, no mention of the first request needing to be HEAD https://httpwg.org/specs/rfc7233.html#rfc.section.2.3

amcasey commented 3 months ago

I'm not sure I understand the question. Could you tell us more about the initial request? It sounds like it might be a GET without a range header and you want to return the content-length of the target resource but not its actual content?

amcasey commented 3 months ago

Here's an RFC I found, no mention of the first request needing to be HEAD https://httpwg.org/specs/rfc7233.html#rfc.section.2.3

Incidentally, I think the latest version is here: https://www.rfc-editor.org/rfc/rfc9110.html#section-14

catmanjan commented 3 months ago

I'm not sure I understand the question. Could you tell us more about the initial request? It sounds like it might be a GET without a range header and you want to return the content-length of the target resource but not its actual content?

Yes that's correct - I've run into this issue with PDF.js (Firefox's default PDF viewer), the initial request is always a GET and its up to the server to choose to return a Content-Length and no content to signal the client that it should swap into range request mode.

One of the justifications for this design (rather than always doing a HEAD first) is that temporary file hosts - e.g. links which expire after being loaded once - will respond to the HEAD request and invalidate the link, meaning the subsequent GET will fail.

As per that RFC link I think the way PDF.js is doing it is correct: "...designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability..."

amcasey commented 3 months ago

Yes that's correct - I've run into this issue with PDF.js (Firefox's default PDF viewer), the initial request is always a GET and its up to the server to choose to return a Content-Length and no content to signal the client that it should swap into range request mode.

How would the server distinguish between GETs that want the content and GETs that just want the length? Maybe you're saying your particular server only gets the latter? That's certainly not a standard use of GETs.

One of the justifications for this design (rather than always doing a HEAD first) is that temporary file hosts - e.g. links which expire after being loaded once - will respond to the HEAD request and invalidate the link, meaning the subsequent GET will fail.

I'm not familiar with such services, but it seems surprising that they'd invalidate on HEAD - the content clearly hasn't been retrieved.

As per that RFC link I think the way PDF.js is doing it is correct: "...designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability..."

I think the line you excerpted says the server is permitted to return the full content (i.e. the normal behavior when a server receives a GET), rather than implementing rangs. I don't think it lets you return a content-length but no content.

catmanjan commented 3 months ago

Looks like we're just going to use IIS