If the EVHTTP_URI_NONCONFORMANT flag is passed in (which it is when
parsing URIs we get over the wire), then we relax our checks a lot.
Specifically, we do nothing to check for correct characters in the
path, query, and fragment parts of such a URI.
We could do much more here: we could relax our hostname requirements,
deal with spaces differently/better, trap some errors but not others,
etc. But this should solve the worst user-agent compatibility issues
for now; the other issues can wait for a later release.
Previously, debug logs were turned on if you built with -DUSE_DEBUG
and off otherwise. This make builds with -DUSE_DEBUG hideously slow
and other builds unable to get debug logs.
This is based off a patch by Ralph Castain from October. It tries a
little harder to avoid needless function calls, it doesn't require
stdbool, and makes the controlling parameter a mask rather than a
boolean so that we can later support enabling only the debugging
messages for the parts of Libevent you're trying to debug.
evhttp needs to be mindful of all hostnames and addresses that clients
use to contact the main server and vhosts to know the difference between
proxy requests and non-proxy requests.
This patch defines enumerators for all HTTP methods that exist
(including PATCH introduced in RFC 5789).
It also makes them bit-masky (that's not a word, is it?), breaking
binary- but not source-code compatibility.
evhttp now stores a bitmask specifying for which methods requests to
dispatch and which ones to reject with "405 Method Not Allowed".
By default that's the ones we currently have (GET, POST, HEAD, PUT,
DELETE), thereby keeping functional compatibility (besides the minor
change that one of the other methods will now cause 405 instead of
400. But I believe that could even be considered a bug-fix).
evhttp is extended by evhttp_set_allowed_methods() with which the
user can change that bitmask.
no regressions here and my test-app still works. Haven't yet
actually tested any of the new methods.
What's obviously missing here is the special logic for the methods:
OPTIONS: We should be fine here - I believe our current dispatch
logic should work fine. Some convenience functions would be fine
though.
TRACE: I'm pretty certain we should never dispatch this to the
callbacks and simply implement the necessary functionality built-in.
CONNECT: Pretty straight-forward to implement (and considering the
framework in which we implement it very efficient too). Should
probably go built-in.
PATCH: Except for checking the RFC against our pre-dispatch logic
(there just might be some "MUST not have Some-Header" lurking
somewhere) there is nothing to be done here, this is completely up
to the user. Nothing to do.
We had to turn a couple of 32-bit size arguments into 64-bit arguments
or size_t arguments (since otherwise we would have had to do it post
2.0.x-stable, and that would be worse).
Someday, when networks are far faster and people frequently want a
burst value greater than 2GB per tick, this will seem very forsightful
indeed.
For now, it breaks ABI, but not source. Fixes bug 3092096.
This change has no effect on non-windows platforms, since those
either define off_t to 64-bits, or allow you to decide whether
it should be 64-bits yourself via some LARGEFILE-like macro.
On Windows, however, off_t is always 32-bit, so it's a bad choice
for "file size" or "file offset" values. Instead, I'm adding
an ev_off_t type, and using it in the one place where we used
off_t to mean "the size of a file" or "an offset into a file" in the
API.
This breaks ABI compatibility on Windows.
