Closed sandorfr closed 7 years ago
Honestly for edge cases they're better off copying the code and tailoring it to their scenarios. What we have is very specific to our scenarios. E.g. we choose not to support more than one range.
The previous code base was supporting multiple range https://github.com/aspnet/StaticFiles/blob/f0c85abbaf9e9e07bd39bc18943a307dd79a1e0a/shared/Microsoft.AspNetCore.RangeHelper.Sources/RangeHelper.cs
This is the kind of utility function which would make sense to be fully implemented to match the applicable RFC and available publicly in the framework.
However this is not critical so I'll live with copy pasting the code for now ;)
RangeHelper provides the required parsing logic for Range Header. When we need to implement range support on something else than static files we currently have to copy paste that code. Would be nice if it was made public as it's definitely reusable and tested code.
I understand that with builtin support for File Results coming in dotnet core 2 most people won't need it, but there are still edge cases where one might need to implement a custom Result.