You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 19, 2019. It is now read-only.
When receiving request with Accept header without value, http.sys crashes with the following stack trace:
at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount)
at Microsoft.AspNetCore.Server.HttpSys.HeaderEncoding.GetString(SByte* pBytes, Int32 byteCount)
at Microsoft.AspNetCore.Server.HttpSys.NativeRequestContext.GetKnownHeader(HttpSysRequestHeader header)
at Microsoft.AspNetCore.Server.HttpSys.RequestHeaders.get_Accept()
at Microsoft.AspNetCore.Server.HttpSys.RequestHeaders.<PropertiesEnumerable>d__201.MoveNext()
at System.Linq.Enumerable.<ConcatIterator>d__58`1.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
...
throwing and returning 500 Internal Server Error, preventing further execution. In our scenario, it happens when client invoke web method returning no-value (so Accept doesn't really matter, as no response is expected really).
IETF recommendations are not super-clear on empty values as header values though, but in this case, it feels right for it to correspond to Accept * / * reather than sending back error; it definitely should not crash with 500.
Given that application developers don't have control over clients in general, and that those invocated methods are not expected to return anything, we might want to serve requests with empty Accept header still.
When receiving request with Accept header without value, http.sys crashes with the following stack trace:
throwing and returning 500 Internal Server Error, preventing further execution. In our scenario, it happens when client invoke web method returning no-value (so Accept doesn't really matter, as no response is expected really).
IETF recommendations are not super-clear on empty values as header values though, but in this case, it feels right for it to correspond to Accept * / * reather than sending back error; it definitely should not crash with 500.
Given that application developers don't have control over clients in general, and that those invocated methods are not expected to return anything, we might want to serve requests with empty Accept header still.
It seems the similar issue was addressed in Kestrel too: aspnet/KestrelHttpServer#429
The text was updated successfully, but these errors were encountered: