It looks like wapp behaves incorrectly when the request line doesn't arrive all at once. Probably the same applies to other header lines.

Example: start a simple hello-world server listening on 127.0.0.1 port 8850, and then run run this tcl program on the same machine:

set s [socket 127.0.0.1 8850]
puts -nonewline $s {G}
flush $s
after 1000
puts $s "ET / HTTP/1.1\n"
flush $s
puts "result: [gets $s]"

Output is result:

If I comment out the flush $s line, output is result: HTTP/1.1 200 Ok

I couldn't find any other mention of this bug, but perhaps this forum post could be related: https://wapp.tcl-lang.org/home/forumpost/7bb16e5f64

I found this while trying to understand how wapp does non-blocking I/O. It looks like wappInt-http-readable-unafe should be checking whether gets returns an empty string.