Support for OPTIONS and HEAD methods

[Goldziher]

Currently Starlite does not support OPTIONS and HEAD methods because we do not use the Starlette routing system. In Starlette, these two methods are automatically set of GET routes. This though does not seem to be the correct way to handle this.

For OPTIONS specifically we need to factor in the behaviour of the CORS middleware, which can in priniciple accept OPTIONS preflight requests. The Starlette CORSMiddleware implements this in such a way that preflight responses are returned for OPTIONS only when the header Access-Control-Request-Method is set. I am not certain this is the correct behaviour and we need to clarify this, we might need to either subclass the Starlette middleware or create our own version if it isn't the desired behaviour.

Otherwise for OPTIONS I think we should probably resolve this with a special method that populates the Allow header. The question really is what values need to be returned from this method, which will determine where and how implementation should look.

HEAD is a different creature. In principle we can use GET request handlers for this, but switch the status code to 204 and strip the body. The problem is that users might create GET handlers that perform side effects etc. and this is going to be an issue. We might therefore consider adding an explicit @head route handler, but I am not certain.

Please add you thoughts.

[provinzkraut]

The problem is that users might create GET handlers that perform side effects etc. and this is going to be an issue. We might therefore consider adding an explicit @Head route handler, but I am not certain.

+1 for this approach. GET handlers might also be possible computationally expensive, which would be wasted if the body is generated and then thrown away