Imagine server side is buggy and miscalculates Content-Length: in the
reply. Data arriving in idle state shouldn't make us crash, instead we
can just reset the connection.
https://sourceforge.net/tracker/index.php?func=detail&aid=3078187&group_id=50884&atid=461324
The problem is that bufferevent_disable() doesn't disable EV_WRITE
when 'connecting' flag is set. However from evhttp_connection_reset()
we want to disable EV_WRITE for sure (we are closing the socket next).
So we add bufferevent_disable_hard(), which acts like
bufferevent_disable(), but resets 'connecting' flag before the call to
the actual handler.
TODO: bufferevent_disable_hard() shouldn't be public, remove it from
event2/bufferevent.h.
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.
f700566c removed a line from evhttp_connection_stop_detectclose that
cleared the EVHTTP_CON_CLOSEDETECT flag. I think this was an
accident, and suspect that it may be the cause of bug 3069555.
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.
When we call evhttp_get_bodylen() [when transfer-encoding isn't set],
having req->ntoread == -1 means that we have no content-length. But a
request with no content-length has no body! We were treating the
absent content-length as meaning "read till closed", which only holds
for replies, not requests.
This patch also allows PATCH requests to have a body.
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).
The trigger for starting to read the first line of a request used to
be, "When data has arrived and we're looking for the first line."
But that's not good enough: if the entire next request gets read
into our bufev->inbuf while we're still processing the current
request, we'll never see any more data arrive, and so will never
process it.
So the fix is to make sure that whenever we hit evhttp_send_done, we
call evhttp_read_cb. We can't call it directly, though, since
evhttp_send_done is reachable from the user API, and evhttp_read_cb
can invoke user functions, and we don't want to force everyone to
have reentrant callbacks. So, we use a deferred_cb.
Found by Ivan Andropov. This is bug 3008344.
We were using evbuffer_add_buffer, which moved the entire buffer
contents. But if we had a valid content_length, we only wanted to
move up to the amount of data remaining in ntoread. Our bug would
make us put our ntoread in the negative, which would in turn make us
read all data until the connection closed.
Found by Denis Bilenko. Should fix bug 2963172.
