HEAD raises an exception

[daveisfera]

When a HEAD request is received by the server, it raises an exception and this makes our server's log noisy when bots and such hit it. Ideally, this would be handled with a 405 or passed to the process_request method with an indication that it's a HEAD instead of a GET to be handled there.

[aaugustin]

That's a valid feature request. Which server are you using? websockets.asyncio.server.serve?

[aaugustin]

At first sight, I would do it in the Sans-I/O layer so all implementations benefit from it, to be confirmed after looking at feasibility.

[daveisfera]

I'm using serve from websockets.sync.server but the issue can also be reproduced with the asyncio server in the example on the main page. Just start that up and hit with curl using -X HEAD and the exception happens.
Technically, replying with an upgrade request just like a GET would probably be fine (i.e. the response to a HEAD is supposed to be the same as a GET but without the body) but I don't know how useful that is in practice, so if it's easier to reply with a 405 METHOD_NOT_ALLOWED then that's great by me.

[daveisfera]

And on a related note, replying to a PUT/POST/DELETE/etc with a 405 instead of raising an exception would also be great. Most spiders use a HEAD or GET but there's plenty of bots out there doing all sorts of horrible things and handling those gracefully instead of with a raised exception would make my logs happier.

[aaugustin]

Yes it makes sense to return 405 on anything that isn't a GET.

[daveisfera]

I noticed that the PR to try resolving this was closed because it wasn't consistent in the handling of the error response, so I took a look at doing it, but I'm not sure what the better way to handle this would be. By the time the handshake in sync/server.py is called, there's not a valid request object so the rest of the parsing and response aren't called. I tried putting in handling there to send a response, but it caused other issues with the handling, so where is the "best" place to handle this so that valid responses are sent for these invalid requests? (from my limited understanding of the code, it appears that all of the places that raise a ValueError in http11.py will run into this same issue and aren't handled, so look like a large approach to handle all of these would be ideal, if possible).