Incomplete support for OPTIONS method

The specification for the OPTIONS method in [RFC 2616, section 9.2](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2) includes the following:

> If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

Because the Requests API only uses full URLs, it is currently impossible to make an `OPTIONS *` request as described above.


You're quite right.

I'm not sure that's so big a problem though. As discussed, it's not a hugely useful request in and of itself, and it's deeply unclear how we'd structure the API to make such a request useful. What's your use case?


My particular use case for such a request is that I'm using it as a lightweight "ping" to allow a server to identify itself to clients as a basic sanity check in the client code (e.g.: instantiating the client with "example.com" as the server URL will raise an exception unless the IANA makes some malicious changes).

I agree that it's not terribly clear how the API would be structured; the best that I can come up with would be to accept an iterable pair of strings as an alternative to the single string URL parameter. i.e.:

```
# request "OPTIONS *" from the server at example.com
requests.request("OPTIONS", ("http://example.com", "*"), *args, **kwargs)

# request "GET /index.html" from the server at example.com
requests.get(("http://example.com", "/index.html"), *args, **kwargs)

# request "GET /" from the server at example.com
request.get("http://example.com", *args, **kwargs)
```


Hmm: is there any reason using the root isn't good enough? e.g. ending up with `OPTIONS / HTTP/1.1`?


As a side note, the correct updated references are [RFC 7230, Section 5.3.4](http://tools.ietf.org/html/rfc7230#section-5.3.4) and [RFC 7231, Section 4.3.7](http://tools.ietf.org/html/rfc7231#section-4.3.7)


> Hmm: is there any reason using the root isn't good enough? e.g. ending up with `OPTIONS / HTTP/1.1`?

For my particular use case: No, there really isn't. Arguably, the HEAD method could probably work, too.

There are probably use cases out there which would require the use of `OPTIONS *` over `OPTIONS /`, but it does not seem to be used very heavily, so this issue definitely doesn't demand a very high priority. Still, because it is a gap in the library's implementation of the HTTP spec, it's an issue that I thought may need to be addressed in the long run. But then again, it may not; after all, the standard `httplib` module does indeed provide this less-used functionality at the cost of a lower-level interface and more complex API.


@jeffg-vsn the problem is that I'm not even confident that `urllib3` supports this behaviour, which makes requests support of it that much more difficult.


I'm quite prepared to believe that nothing above `httplib` makes this possible.


I guess you _could_ do something like this **in** `httplib`:

``` python
import httplib

conn = httplib.HTTPConnection('domain', 80)
conn.request('OPTIONS', '*')
r = conn.getresponse()
```

But I just cannot imagine how we would accept that in urllib3 or requests.


We would have to special-case this the whole way down the stack.


@Lukasa yeah. I'm pretty sure we can't really do anything about this sadly. Closing until that changes.