Enable all HTTP methods by default

[libevent]

Enable all HTTP methods by default

[nmathewson]

Wouldn't this break existing code for anybody who was relying on not getting anything other than the current defaults? If so, that's a bit red flag: we really don't like to break existing code.

[lkraider]

I understand the concern, but my reasoning is that it is a hassle for those that do need all the RFC specified methods, specially when libevent is actually wrapped by other libraries.

gevent is such a case: its wrapping only forwards whatever the default libevent http server forwards, which means users only get partial HTTP support there. Many don't notice this because OPTIONS, TRACE and CONNECT are rarely used, but for those that do need them it is a real problem, even to find out who is actually responding those requests.

I don't presume to know how it would affect all current libevent users and implementations, but my understanding is that libraries should not cater their API to a specific use-case, which is how it is implemented now declaring some default methods as unsupported, but actually provide for the general cases and strive for specification-compliance. Benefits of course include not having to read the docs or source-code to understand their workings and overall avoid surprises for users.

[nmathewson]

I see where you're coming from, but why can't gevent call "evhttp_set_allowed_methods()" to enable more methods if it's capable of supporting them?

I agree that it would have been better if the original API had supported all of these methods by default back when Niels created it. But as things stand now, there are quite likely programs out there that will not behave correctly if their evhttp callbacks get an OPTIONS, TRACE, or CONNECT request. One of the reasons people are willing to write programs with Libevent is that we promise pretty sincerely that we won't gratuitously break working code that used our APIs as documented without an excellent reason ... and "the original API was stupid" is not such a good reason.

The right way to change an API like this would be to do what we did with event_set() and event_init() in Libevent 2.0 -- deprecate the old, broken API and make a new, recommended API with more sensible behavior. That's one possibility here too.

We should also look at what Mark Ellzey's libevhtp library does here; at the moment, it's in most respects a better http server than Libevent's built-in evhttp code, and I'd eventually like to deprecate evhttp entirely in favor of a thin wrapper around libevhtp. If libevhtp has a better initialization API, it might sense to converge on that, and deprecate the existing evhttp_new().

[lkraider]

Yes, it is a problem with the gevent guys not having read the docs about the libevent server, and it is a straightforward fix, or should be, they are currently moving to libev, I don't know how the support for the current stable version is going to be.

Since there is that promise for libevent not breaking its previous API, it is probably better to consider this only for a future version then as you say.

libevhtp looks interesting, thanks for pointing it out.

[errzey]

Since gevent doesn't use libevent anymore, and this is really old, closing.