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.
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.
Remember, the code
int is_less_than(int a, unsigned b) {
return a < b;
}
is buggy, since the C integer promotion rules basically turn it into
int is_less_than(int a, unsigned b) {
return ((unsigned)a) < b;
}
and we really want something closer to
int is_less_than(int a, unsigned b) {
return a < 0 || ((unsigned)a) < b;
}
.
Suggested by an example from Ralph Castain
(The existing implementation had sanity-checking code for the case where
its argument was NULL, but it erroneously dereferenced it before actually
doing the sanity-check. --nickm)
The current template...
<HTML><HEAD><TITLE>%s</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
Invalid method in request<P>
</BODY></HTML>
is highly confusing. The given title is easily overlooked and the
hard-coded content is just plain wrong in most cases (I really read
this as "the server did not understand the requested HTTP method)
This patch changes the template to include the error reason in the
body as well as in the header, and to infer the proper reason from
the status code whenever the reason argument is NULL.
This patch also removes a redundant evhttp_add_header from
evhttp_send_error; evhttp_send_page already adds a "Connection:
close" header.
If Libevent uses strcpy, even safely, it seems OpenBSD's linker will
complain every time a library links Libevent. It's easier just not to
use the old thing, even when it's safe to do so.
It turns out that _REENTRANT isn't only needed to make certain
functions visible; we also need it to make pthreads work properly
some places (like Solaris, where forgetting _REENTRANT basically
means that all threads are sharing the same errno). Fortunately,
our ACX_PTHREAD() configure macro already gives us a PTHREAD_CFLAG
variable, so all we have to do is use it.
The EVUTIL_CLOSESOCKET() macro required you to include unistd.h in your
source for POSIX. We might as well turn it into a function: an extra
function call is going to be cheap in comparison with the system call.
We retain the EVUTIL_CLOSESOCKET() macro as an alias for the new
evutil_closesocket() function.
(commit message from email by Nick and Sebastian)
Remeber, win32 has a socket type that's actually a handle, so if
there's a chance that code is run on win32, we can't use "int" as the
socket type.
This isn't a blind search-and-replace: sometimes an fd is really in
fact for a file, and not a socket at all.
when sending chunked requests via multiple calls to evhttp_send_reply_chunk,
the client may close the connection before the server is done sending. this
used to cause a crash.
we introduce a new function evhttp_request_get_connection() that allows the
server to determine if the request is still associated with a connection.
If it's not, evhttp_request_free() needs to be called explicitly or the user
can call evhttp_send_reply_end() which just frees the request, too.
