4 ms·

Is it really OK to add a new method to HTTP 1.1? I think would be quite an unfortunate decision, because it would make the version numbers absolutely meaningles

Is it really OK to add a new method to HTTP 1.1? I think would be quite an unfortunate decision, because it would make the version numbers absolutely meaningless if all of a sudden new methods can pop up without them changing.

politician 5y ago
HTTP 1.1 makes it clear that the method mechanism is extensible [1]. Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | "CONNECT" | 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." [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5....
- qalmakka 5y ago
  Thanks, it makes sense now. I had the feeling I was missing something, I haven't really ever read the HTTP spec TBH so I was not aware of this.
- derefr 5y ago
  And, indeed, this has been done many times, by e.g. WebDAV (methods COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, UNLOCK).
jdlshore 5y ago
The short version is that it's perfectly fine. This doesn't modify the HTTP spec, and it uses established extension mechanisms. The long version: RFC 7231 defines the standard HTTP methods in section 4.1. [1] Looking at it, the only methods that are required are GET and HEAD. All others are optional, and the spec explicitly calls out that additional methods may be created and registered with the IANA. Looking closely at this RFC reveals two things: 1. It doesn't modify any of the HTTP RFCs. (There's no "Obsoletes" or "Updates" header.) 2. In section 6 of the QUERY RFC, it requests that the IANA add the new method to its registry. That follows the guidelines in RFC 7231 section 4.1. [1] https://datatracker.ietf.org/doc/html/rfc7231#section-4.1 https://datatracker.ietf.org/doc/html/rfc7231#section-4.1

politician 5y ago

HTTP 1.1 makes it clear that the method mechanism is extensible [1]. Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | "CONNECT" | 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." [1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1 https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5....

qalmakka 5y ago
Thanks, it makes sense now. I had the feeling I was missing something, I haven't really ever read the HTTP spec TBH so I was not aware of this.
derefr 5y ago
And, indeed, this has been done many times, by e.g. WebDAV (methods COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, UNLOCK).

jdlshore 5y ago

The short version is that it's perfectly fine. This doesn't modify the HTTP spec, and it uses established extension mechanisms. The long version: RFC 7231 defines the standard HTTP methods in section 4.1. [1] Looking at it, the only methods that are required are GET and HEAD. All others are optional, and the spec explicitly calls out that additional methods may be created and registered with the IANA. Looking closely at this RFC reveals two things: 1. It doesn't modify any of the HTTP RFCs. (There's no "Obsoletes" or "Updates" header.) 2. In section 6 of the QUERY RFC, it requests that the IANA add the new method to its registry. That follows the guidelines in RFC 7231 section 4.1. [1] https://datatracker.ietf.org/doc/html/rfc7231#section-4.1 https://datatracker.ietf.org/doc/html/rfc7231#section-4.1