After having had a closer look at the code, I don't think that the query method which takes a METHOD as an argument should be specific to the HTTP server implementation – METHOD is defined in SolrRequest, i.e. it's not specific to HTTP requests. It looks like METHOD was really meant to provide a general way of passing non-solr parameters to requests.
If we decided that the METHOD is really just HTTP specific and shouldn't be in the general request class – it's used nowhere but in the HTTP server – then a significant amount of refactoring will be necessary to implement everything properly. One way to do this would be to introduce a new interface, HttpParameters, and have a subclass for each type of request implement that interface. Then change the HTTP server implementation to only work with requests which implement that interface. This is probably big enough to be handled in a different issue though.
Alternatively the METHOD could be moved to the HTTP server implementation, making it a property of the server and not of the request. I don't like that option though because different requests have different defaults for the METHOD (e.g. update requests POST, query requests GET) and moving this information requires the server to know how to handle which type of request.