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.
The old evhttp_decode_uri() function would act as tough it was doing
an (illegal, undefined) decode operation on a whole URL at once, and
treat + characters following a ? as different from + characters
preceding one. But that's not useful: If you are decoding a URI
before splitting off query parameters, you are begging to fail as soon
as somebody gives you a value with an encoded & in it.
The new evhttp_uridecode() function takes an argument that says
whether to decode + signs. Both uridecode and uriencode also now
support encoding or decoding to strings with internal 0-valued
characters.
Perviously, some characters not listed as "unreserved" by RFC 3986
(notably "!$'()*+,/:=@") were not encoded by evhttp_encode_uri. This
made trouble, especially when encoding path components (where @ and /
are bad news) and parameters (where + should get encoded so it doesn't
later decode into a space).
Spotted by Bas Verhoeven.
We already detected certain malformed queries, but we responded by
aborting the query-parsing process half-way through without telling
the user. Now, if query-parsing fails, no headers are returned, and
evhttp_parse_query returns -1.
This reverts commit fab50488fcb741884ccdfa7b83643eac3e5c9cbf.
The function was, on reflection, not important enough to break the feature
freeze, since it's trivial to build on your own.
The evhttp_parse_query API is a bit misdesigned; all the other
evkeyvalq stuff is abstract and lets you get away with having a header
stub, but evhttp_parse_query seems to require that you instantiate an
empty evkeyvalq of your own.
The interface from the user's POV is similar to the locking
implementation: either provide a structure full of function
pointers, or just call evthread_use_*_threads() and everything will
be okay.
The internal interface is meant to vaguely resemble pthread_cond_*,
which Windows people will better recognize as *ConditionVariable*.
Though the C standards allow it, it's apparently possible to get MSVC
upset by saying "struct { int field; } (declarator);" instead of
"struct {int field; } declarator;", so let's just not do that.
Bugfix for 3044492
(commit msg by nickm)
As a generated file, it shouldn't get included in our source
distribution. Apparently there is an automake incant for this:
nobase_ even stacks with nodist_ .
