Comments (5)
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.
from libevent.
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.
from libevent.
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().
from libevent.
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.
from libevent.
Since gevent doesn't use libevent anymore, and this is really old, closing.
from libevent.
Related Issues (20)
- feature request: http/3 client HOT 2
- windows socks5 combo mbedtls client: [warn] BUG: Unexpected mbedtls error code -29184: SSL - An invalid SSL record was received HOT 1
- Class member functions to be param callback of event_new HOT 1
- deadlock on event_del_nolock_() HOT 2
- Segmentation fault after bufferevent_write HOT 7
- bufferevent_write deadlock HOT 4
- buffereven_write blocking problem HOT 1
- HTTP parser allows empty header names
- How to verify libevent release download with provided asc file? HOT 1
- New security rules (NULL check) HOT 3
- New security rules (other type)
- Websocket connection fails with 404 for request header "Connection: keep-alive, Upgrade" (Firefox) HOT 4
- HTTP parser does not properly strip spaces and tabs from the beginnings of header values
- Hard coding of unknown IP addresses(1.2.3.4 and 18.244.0.188) HOT 1
- NDK 编译 libevent + openssl
- NDK 编译 libevent-2.1.8-stable + openssl;成功编译
- Unexpected DNS resolve procedure if dual stack enviroment and multiple subdomain exists HOT 1
- lost call http_request_done sometimes as httpclient
- Support 16KB page size devices
- mbedstl double free (libevent-2.2.1-alpha-dev)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libevent.