Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
FileStreamResult writes to response body for HTTP HEAD when range processing is enabled #7208
I was reviewing some code in order to see how ASP.NET has implemented streaming and I came across something which I believe is a bug, but I haven't tested it, so forgive me if I'm wrong.
I have noticed that if there is a HTTP HEAD request made where range processing is enabled that the
Can this be correct?
Also would you be interested in moving the basic functionality of streaming into the core ASP.NET project so it could be used from other frameworks such as Giraffe without having to copy the implementation?
I think it should be easily possible to create a method for
I think this bug has been introduced, because a
changed the title from
FileStreamResult writes to response body for HTTP HEAD with valid range header
FileStreamResult writes to response body for HTTP HEAD when range processing is enabled
Jan 8, 2018
@Tratcher - what at the deltas between what MVC does and https://github.com/aspnet/HttpAbstractions/blob/87cd79d6fc54bb4abf07c1e380cd7a9498a78612/src/Microsoft.AspNetCore.Http.Extensions/SendFileResponseExtensions.cs ?
Trying to help @dustinmoris question from the OP
SendFileAsync's sole function is to copy the contents of the file to the network. It's a glorified
MVC can check request headers like Range or If-xxx and alter the response accordingly. It will also set response headers like content-type, content-length, etag, last-modified, etc..
Yes agreed, I think it would be hugely beneficial to have a range of HttpContext extensions which can do some of this common work. The MVC
Similar things already exist with other complex things like
I think this is a good approach and I would love to see this type of architecture take place in other domains of ASP.NET Core as well.
referenced this issue
Jan 10, 2018
added a commit
Jan 11, 2018
Hello, thanks for the prompt fix! Sorry for being annoying, but I am implementing something similar in a different application right now and reading all the RFCs and related docs and then comparing it to how MVC has done it as a point of reference and I think I just noticed another very minor bug.
This one can be probably fixed quicker than me creating a new issue, but if you guys prefer to split it out into a new issue and the architectural question as well then I'm happy to do it - just let me know!
@Tratcher Looks like in
referenced this issue
Jan 12, 2018
Last question on the topic of
Hmmm. For background this code was pulled over from StaticFiles where there's always an e-tag. The absence of an e-tag hasn't been thought through.
"It can also be used with safe
It doesn't say what to do if the server can't provide an e-tag for the resource. However, e-tags are opaque tokens and are only provided by the server. For a client to have and send one it must have gotten it from the server on a prior request. In this regard I'd expect consistent behavior from the server, either always or never providing an e-tag for a given resource. That makes it extremely unlikely that we'd see this mismatch scenario in real life scenarios, so the existing behavior is probobly fine.