Repository navigation
[API Proposal]: Ascii.ToUtf16 overload that treats \0 as invalid #80366
Description
Background and motivation
For ASP.NET Core's StringUtilities the ASCII values of the range (0x00, 0x80) are considered valid, whilst Ascii.ToUtf16 treats the whole ASCII range [0x00, 0x80) as valid. In order to base StringUtilities on the Ascii-APIs and avoid custom vectorized code in ASP.NET Core internals \0 should be allowed to be treated as invalid. See dotnet/aspnetcore#45962 for further info.
API Proposal
namespace System.Buffers.Text
{
public static class Ascii
{
// existing methods
+ public static OperationStatus ToUtf16(ReadOnlySpan<byte> source, Span<char> destination, out int bytesConsumed, out int charsWritten, bool treatNullAsInvalid = false);
}
}The new ASCII-APIs will get added to .NET 8, so w/o breaking change an optional argument could be added.
namespace System.Buffers.Text
{
public static class Ascii
{
// existing methods
- public static OperationStatus ToUtf16(ReadOnlySpan<byte> source, Span<char> destination, out int bytesConsumed, out int charsWritten);
+ public static OperationStatus ToUtf16(ReadOnlySpan<byte> source, Span<char> destination, out int bytesConsumed, out int charsWritten, bool treatNullAsInvalid = false);
}
}API Usage
private static unsafe void GetHeaderName(ReadOnlySpan<byte> source, Span<char> buffer)
{
OperationStatus status = Ascii.ToUtf16(source, buffer, out _, out _, treatNullAsInvalid: true);
if (status != OperationStatus.Done)
{
KestrelBadHttpRequestException.Throw(RequestRejectionReason.InvalidCharactersInHeaderName);
}
}Alternative Designs
No response
Risks
The value for treatNullAsInvalid will be given as constant, so the JIT should be able to dead-code eliminate any code needed for "default case" (whole ASCII-range incl. \0), so no perf-regression should be expected.
Besides treating \0 as special value which is optinally treated as invalid I don't expect any other value to be considered special enough for optional exclusion.
Activity
stephentoub commentedon Jan 9, 2023
Does the ASP.NET code measurably regress if the newly-added ToUtf16 is used plus a call to IndexOf((byte)'\0) to validate there wasn't a null?
@GrabYourPitchforks had some fairly strong opinions about special-casing
'\0'.gfoidl commentedon Jan 9, 2023
In local micro-benchmarks yes, mainly due to the$O(2n)$ -nature. And of course it depends on the input (length and position of
\0).It would be more interesting to see real-usage benchmarks, like how that would impact Techempower, etc. But unfortunately I don't know how to run such benchmarks (at the moment).
I'm looking forward to read them.
benaadams commentedon Jan 9, 2023
99% of the time there won't be any nulls but headers average 800 bytes to 2kB with cookies; so scanning the headers an additional time to check for nulls can be significant
gfoidl commentedon Jan 9, 2023
Thanks for these numbers!
Out of interest: how / where did you get these from?
benaadams commentedon Jan 9, 2023
Googled average headers size 😅
As an anecdote going to Google homepage logged in my headers are 2158 bytes and it makes 27 requests to that domain (26 to other domains); so in total 58kB for that page and one domain
svick commentedon Jan 9, 2023
Wouldn't it be better to treat
\0as special at the highest level, instead of at the lowest level?For example, I think that when parsing HTTP 1 headers, you could look for
\r,\nor\0as the first step, instead of just\rand\n, and deal with\0at that point. That would then mean you could safely use the current version ofAscii.ToUtf16to convert the header bytes to UTF-16.tannergooding commentedon Mar 23, 2023
Assigning to @GrabYourPitchforks for now until the necessary input can be given.
GrabYourPitchforks commentedon Mar 23, 2023
I am strongly against this proposal. ASCII is defined as characters in the range
0x00 .. 0x7F, inclusive. Sometimes a protocol will exclude certain characters (0x00, or the entire control character range0x00 .. 0x1Fand0x7F), but at that point you're making something tied to a particular protocol rather than something that is a general-purpose ASCII API. It's similar to the reason we don't support WTF-8 within any of our UTF-8 APIs: certain protocols may utilize it, but it doesn't belong in a general-purpose UTF-8 processing API.Since this is protocol-specific for aspnet, I recommend the code remain in that project.
3 remaining items
benaadams commentedon Mar 23, 2023
Spec wise it shouldn't; however if its a front-end server that passes requests to another server; if and that server uses null terminated strings then the request can change in the second layer accessing url's which weren't mapped to the internet, which could be a security risk (along lines of https://en.wikipedia.org/wiki/HTTP_request_smuggling though different)
benaadams commentedon Mar 23, 2023
As @svick says, it just needs to check for 3 rather than 2, then throw if its
\0; is already an api for itstephentoub commentedon Mar 24, 2023
I hadn't seen @svick's comment:
Is that viable? Can all of the places that call into this shared routine be updated trivially to ensure the data passed in doesn't contain a \0? If so, let's do that, add the AScii.ToUtf16 that's for the whole [0, 127] range, update ASP.NET to use that, and call it a good day.
stephentoub commentedon Apr 28, 2023
@BrennanConroy, do you have a suggestion for how we could make forward progress on this?
BrennanConroy commentedon Apr 29, 2023
Looks like it would be "easy" to do this. If we updated https://github.com/dotnet/aspnetcore/blob/f62f12357c49c4f1cca502e8f4cf57353f0b320f/src/Servers/Kestrel/Core/src/Internal/Http/HttpParser.cs#LL64C37-L64C37 to instead be
This is where we start parsing the HTTP/1 request so we're already going through the entire request line looking for
\n, this just updates toTryReadToAnyto search for\0at the same time, which I hope is optimized for single pass 😃.The concerns are:
\0check from theGetAsciiStringNonNullCharactersmethod which means new callers could accidentally allow null\0is found are lacking detail (although a lot faster 😆)GetAsciiStringNonNullCharactersalthough it looked like they were supposed to already be null character checking before calling this methodstephentoub commentedon Apr 29, 2023
Thanks, I sketched it out in:
dotnet/aspnetcore@main...stephentoub:aspnetcore:asciitoutf16
Not exactly what you suggested, but similar.
A bunch of tests failed, and I haven't gone through to see which would be expected (the tests have internals access) and which would be real problems.
Any interest in picking it up and seeing how far we can run with it?
BrennanConroy commentedon Apr 30, 2023
Yeah, I'll pick it up and see what the team thinks
BrennanConroy commentedon May 8, 2023
It looks like
Ascii.ToUtf16is still slower than the custom code in aspnetcore.dotnet/aspnetcore#45962 (comment)
#80245 is open which might be indirectly tracking part of the work to improve the performance.
And there is a recent PR that might improve performance #85266.
stephentoub commentedon May 8, 2023
I'm not aware of any fundamental reason that should be the case. We should fix anything in the core routine that might be contributing those few additional cycles. I'd hope it's not just the difference between returning a bool and returning an OperationStatus.
cc: @adamsitnik, @GrabYourPitchforks
BrennanConroy commentedon Oct 6, 2023
Grabbed the assembly of
Ascii.ToUtf16and Kestrel'sTryGetAsciiStringOne very obvious difference is that the core processing is not inlined in the
Ascii.ToUtf16case. That's the first thing I would try when comparing perf, but it always takes me a couple hours to figure out how to get a custom runtime again, so I haven't tried yet 😆But if someone wants to take a look at the assembly in the meantime and see if there is anything obviously worse in the
Ascii.ToUtf16case please do!Ascii.ToUtf16
TryGetAsciiString
GrabYourPitchforks commentedon Oct 9, 2023
Below are the results I'm getting on my machine. This seems very much within the range of noise.
@BrennanConroy Are you seeing different results than below?
stephentoub commentedon Jan 15, 2024
@BrennanConroy, can you comment on the above?
stephentoub commentedon Jul 19, 2024
Closing given dotnet/aspnetcore#56578