catch Defect in asynchttpserver for bad http request

[YesDrX]

#25819

[tersec]

Is catching Defect necessarily well-defined?

Presumably some other code in this scenario is triggering the issue and that could/should be fixed, minimally, in addition.

This is a workaround of what appears to be some real underlying issue.

For example, parseProtocol should not trigger such an issue, and this doesn't address that at all.

[ringabout]

related to #25568

[YesDrX]

changed to raise ValueError inside parseProtocol rather than catch Defect

 [OK]    valid HTTP/1.1 → (1, 1)
 [OK]    valid HTTP/1.0 → (1, 0)
 [OK]    valid HTTP/2 → (2, 0)
 [OK]    valid HTTP/2.0 → (2, 0)
 [OK]    valid HTTP/3 → (3, 0)
 [OK]    garbage prefix → ValueError (as expected)
 [OK]    empty string → ValueError (as expected)
 [OK]    HTTP/ only (THE CRASH) → ValueError (as expected)
 [OK]    HTTP/1 (no dot) → (1, 0)
 [OK]    HTTP/. (dot only) → ValueError (as expected)
 [OK]    HTTP/1. (no minor) → ValueError (as expected)
 [OK]    HTTP// (double slash) → ValueError (as expected)