Zig Version
0.17.0-dev.835+09bb2315e
Steps to Reproduce, Observed Behavior, and Expected Behavior
With Server's request handling, a client can trivially craft a request that causes asserts to fail, which will cause the server to crash when built with checked unreachable.
This can be easily reproduced with request curl -iX POST <url> against env ZIG_DEBUG_CMD=1 zig std.
thread 225966 panic: reached unreachable code
/home/loweg/Source/zig/build/stage3/lib/zig/std/debug.zig:423:14: 0x1049ea9 in assert (std.zig)
if (!ok) unreachable; // assertion failure
^
/home/loweg/Source/zig/build/stage3/lib/zig/std/http/Server.zig:631:27: 0x1224d96 in discardBody (std.zig)
assert(request.head.transfer_encoding != .none or request.head.content_length != null);
^
/home/loweg/Source/zig/build/stage3/lib/zig/std/http/Server.zig:350:47: 0x12abd4d in respondUnflushed (std.zig)
const keep_alive = request.discardBody(server_keep_alive);
^
/home/loweg/Source/zig/build/stage3/lib/zig/std/http/Server.zig:328:29: 0x12ab75d in respond (std.zig)
try respondUnflushed(request, content, options);
^
/home/loweg/Source/zig/build/stage3/lib/zig/compiler/std-docs.zig:180:24: 0x1207778 in serveDocsFile (std-docs.zig)
try request.respond(file_contents, .{
^
These assertions appear to be intended to document what the spec allows. My expectation would be that a server would be generous in what it accepts and any asserts should only validate what the server produces. If std.http does not want to handle requests that are not perfectly spec-compliant, it should contain code to validate and reject them, rather than unexpected asserts.
This essentially prevents using a ReleaseSafe server build (which seems like a good practice) in production, as it leaves open a trivial DoS that would need to be worked around. It could also potentially introduce UB if the compiler relies on the asserts.