Skip to content
This repository has been archived by the owner on Nov 6, 2022. It is now read-only.

Custom methods should be supported #309

Open
nazar-pc opened this issue May 25, 2016 · 7 comments
Open

Custom methods should be supported #309

nazar-pc opened this issue May 25, 2016 · 7 comments

Comments

@nazar-pc
Copy link

Initially reported here: nghttp2/nghttp2#602

I see in sources big switch with hardcoded HTTP methods and rejects any custom methods, however, there is nothing in specs that forbids usage of custom methods (see referred issue for examples).

@indutny
Copy link
Member

indutny commented May 25, 2016

@nazar-pc what about Content-Length and Transfer-Encoding should it be accepted for custom methods, or should we reject methods that pass them? There are some protocol driven semantics that may be very important to implement additional methods.

@nazar-pc
Copy link
Author

I do not think there is something fundamentally different here.
As per https://tools.ietf.org/html/rfc7231#section-4 I suppose methods not listed in spec are:

  • not safe
  • not idempotent
  • not cacheable (I feel like caching might actually apply if corresponding headers are present though)

Content-Length and Transfer-Encoding do not seem to be specifically tied to methods. So I'd expect custom methods to support them if present. This is what Apache2 and Nginx at least both do in practice and modern browsers also do not have any issues with this. So I'm using custom methods in API when sending AJAX requests sometimes with request body, sometimes without. When body is present there is correct Content-Length, if no body - Content-Length header is not present at all.

@indutny
Copy link
Member

indutny commented May 25, 2016

What about Upgrade header? Should it still work as usual with custom methods?

Is it safe to assume that there are no "no-body" methods like HEAD?

@nazar-pc
Copy link
Author

I'm completely confident about Upgrade. It is allowed for some other methods besides GET? Didn't found anything about this.

I think yes, HEAD is pretty special in this meaning, but, obviously, response might have empty body.

@tatsuhiro-t
Copy link
Contributor

If we pretend that custom methods do not require special treatment of HEAD, then we can follow the rule described in https://tools.ietf.org/html/rfc7230#section-3.3.3, to determine the content length.
Of course, this would break if someone standardizes new method which requires special treatment like HEAD or CONNECT.

@tatsuhiro-t
Copy link
Contributor

Here is my PoC #311
I made nghttpx proxy use this new on_method callback, and it works fine.

@Fr0sT-Brutal
Copy link

Fr0sT-Brutal commented May 5, 2017

Any changes on this? Can't wait to see this update applied to have Node parse custom headers.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants