Support custom HTTP methods with bodies.

[blackdigger]

PROPFIND was added. Re-purposing this issue for arbitrary methods allowing bodies. These would obviously be forbidden from any cache interaction as no semantics can be known.

— @JakeWharton

Is it possible to add support for custom HTTP methods such as PROPFIND?
I realize there is a limitation of sun's implementation of HttpUrlConnection, but maybe you have some idea how to work around that?
we use apache http client in our project at the moment mainly because it allows to define custom http method by extending HttpEntityEnclosingRequestBase.
we tried to switch to OkHttp, both core version with HttpUrlConnection and OkApacheClient version - they both throw ProtocolException (probably because both use HttpUrlConnection inside)

[swankjesse]

We should fix this. Limiting the permitted protocols doesn't add value. One catch is that the HTTP method impacts behavior in a number of places. Most notably, for custom protocols like PROPFIND we wouldn't support caching. We also wouldn't know whether the request should carry a body or not.

[swankjesse]

Friends with #386

[swankjesse]

I wrote a test for this, but then discovered we need to know more about the method than just its name. There are rules around which methods have request and response bodies, and how they interact with the cache.

I believe the spec may have something to say about extra methods. I'm going to punt on this for now and come back to it for the next release.

[maevius]

I think the implementors of HttpURLConnection got it wrong here. Clearly the spec states "extension-method". While this is an optional feature for a Server, it doesn't leave any space for a client side provider to speculate on the server side...

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.

   Method         = "OPTIONS"                ; Section 9.2
                  | "GET"                    ; Section 9.3
                  | "HEAD"                   ; Section 9.4
                  | "POST"                   ; Section 9.5
                  | "PUT"                    ; Section 9.6
                  | "DELETE"                 ; Section 9.7
                  | "TRACE"                  ; Section 9.8
                  | "CONNECT"                ; Section 9.9
                  | extension-method
   extension-method = token

The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9.

[rfc2822]

Is there currently any way to use PROPFIND with okhttp?

[rfc2822]

See also PR #1901. Please tell me if I can do further changes, tests, etc for this modification.

[ghost]

1. Hope to have:

   1. make user-defined method (supported now, by Request.method(String, RequestBody))
   2. define the restriction of permitting or not the corresponding body (NOT work, Request.method(String, RequestBody), HttpMethod.permitsRequestBody(method)).

2. Problem

   As all related classes are marked as 'FINAL' (terrible pattern), I need to hack inside the source.

   Hope it can be more open for extension.

3. Tested version:

   okhttp-2.5.0

Thanks.

[dahankzter]

This would be very neat! Now I have to include Apache Http Components for this isolated little thing. :(

[JeroenBer]

Please allow things like PROPFIND with request body. It seems not correct to be strict about custom http methods.