450 Commits

Author SHA1 Message Date
yuangongji
0cd536b0b3
http: rename bind_socket_ai() to create_bind_socket_nonblock() 2019-09-18 23:13:34 +03:00
yuangongji
1c78451f0d
http: make sure the other fields in ext_method are not changed by the callback 2019-09-18 23:12:56 +03:00
Azat Khuzhin
1c573ab3a9
http: do not name variable "sun" since this breaks solaris builds
-bash-3.2$ /opt/csw/bin/gcc -xc /dev/null -dM -E | grep '#define sun'
  #define sun 1
2019-05-25 23:41:38 +03:00
Azat Khuzhin
ad51a3c1ba
http: avoid use of uninitialized value for AF_UNIX/AF_LOCAL sockaddr
unixsock peer does not have sun_path initialized.
2019-05-12 18:21:21 +03:00
Thomas Bernard
8dcb94a4ca
Added http method extending
User can define his own response method by calling
evhttp_set_ext_method_cmp() on the struct http, or
evhttp_connection_set_ext_method_cmp() on the connection.

We expose a new stucture `evhttp_ext_method` which is passed to the
callback if it's set. So any field can be modified, with some exceptions
(in evhttp_method_):

If the cmp function is set, it has the ability to modify method, and
flags. Other fields will be ignored. Flags returned are OR'd with the
current flags.

Based on changes to the #282 from: Mark Ellzey <socket@gmail.com>
2019-04-11 22:48:01 +03:00
Thomas Bernard
96e56beb94
http: Update allowed_methods field from 16 to 32bits. 2019-04-11 22:47:55 +03:00
Azat Khuzhin
799053db8a
http: replace EVHTTP_REQ_UNKNOWN_ with 0
From the server perspective the evhttp_response_phrase_internal() should
not be called with 0 before this patch, it will be called with
EVHTTP_REQ_UNKNOWN_ hence this patch should not change behavior.

Fixes: 68eb526d7b ("http: add WebDAV methods support")
Fixes: #789
Fixes: #796
Reported-by: Thomas Bernard <miniupnp@free.fr>
2019-04-10 00:51:27 +03:00
Alexander Drozdov
68eb526d7b http: add WebDAV methods support
WebDAV introduced new HTTP methods (RFC4918):
PROPFIND, PROPPATCH, MKCOL, LOCK, UNLOCK, COPY, MOVE.

Add support of the methods.
2019-03-14 11:12:46 +03:00
Azat Khuzhin
bf19462a55
http: suppress -Wwrite-string in evhttp_parse_query_impl() 2019-03-13 00:21:38 +03:00
Azat Khuzhin
5ee507c889
http: implement separate timeouts for read/write/connect phase
This patch allows to change timeout for next events read/write/connect
separatelly, using new API:

- client:
  evhttp_connection_set_connect_timeout_tv() -- for connect
  evhttp_connection_set_read_timeout_tv()    -- for read
  evhttp_connection_set_write_timeout_tv()   -- for write

- server:
  evhttp_set_read_timeout_tv()  -- for read
  evhttp_set_write_timeout_tv() -- for write

It also changes a logic a little, before there was next fallbacks which
does not handled in new API:
- HTTP_CONNECT_TIMEOUT
- HTTP_WRITE_TIMEOUT
- HTTP_READ_TIMEOUT

And introduce another internal flag (EVHTTP_CON_TIMEOUT_ADJUSTED) that
will be used in evrpc, which adjust evhttp_connection timeout only if it
is not default.

Fixes: #692
Fixes: #715
2019-03-05 00:33:46 +03:00
Azat Khuzhin
30791eccce
http: try to read existing data in buffer under EVHTTP_CON_READ_ON_WRITE_ERROR
There are two possible ways of getting response from the server:
- processing existing bufferevent buffer
- reading from the socket (even after write() errored with -1, it is
still possible)

But we did not tried the first option, only the second one.

Fixes: http/read_on_write_error (on freebsd/osx)
2019-01-29 01:16:48 +03:00
Azat Khuzhin
d3dcb5aca9
http: do not call deferred readcb if readcb is not set
Otherwise evhttp_read_cb can be called with invalid connection state:
    http/read_on_write_error: [forking] [msg] libevent using: kqueue
      FAIL ../test/regress_http.c:4079: assert(req)
      FAIL ../test/regress_http.c:4087: assert(req)[err] evhttp_read_cb: illegal connection state 0
2019-01-28 22:20:47 +03:00
Luke Dashjr
28d7221b85
http: Preserve socket error from listen across closesocket cleanup
Closes: #738 (cherry-picked)
2019-01-07 15:22:39 +03:00
Azat Khuzhin
f3f7aa5aff
http: fix connection retries when there more then one request for connection
We should not attemp to establishe the connection if there is retry
timer active, since otherwise there will be a bug.

Imagine next situation:
  con = evhttp_connection_base_new()
  evhttp_connection_set_retries(con, 2)
  req = evhttp_request_new()
  evhttp_make_request(con, req, ...)
  # failed during connecting, and timer for 2 second scheduler (retry_ev)

Then another request scheduled for this evcon:
  evhttp_make_request(con, req, ...)
  # got request from server,
  # and now it tries to read the response from the server
  # (req.kind == EVHTTP_RESPONSE)
  #
  # but at this point retry_ev scheduled,
  # and it schedules the connect again,
  # and after the connect will succeeed, it will pick request with
  # EVHTTP_RESPONSE for sending and this is completelly wrong and will
  # fail in evhttp_make_header_response() since there is no
  # "http_server" for this evcon

This was a long standing issue, that I came across few years ago
firstly, bad only now I had time to dig into it (but right now it was
pretty simple, by limiting amount of CPU for the process and using rr
for debug to go back and forth).
2018-12-12 21:46:27 +03:00
Azat Khuzhin
b98d32d0c9
http: improve error path for bufferevent_{setfd,enable,disable}()
We have calls to the next functions but do not check return values,
though they can be invalid and it is better to show this somehow.

Also do bufferevent_setfd() first and only after it
bufferevent_enable()/bufferevent_disable() since:
a) it is more natural
b) it will avoid extra operations
c) it will not fail first bufferevent_enable() (this is the case for
   buffbufferevent_async at least)

In this case we could add more information for issues like #709
2018-11-20 06:22:31 +03:00
Azat Khuzhin
5dc88b387f
Fix conceivable UAF of the bufferevent in evhttp_connection_free()
Although this is not a problem, since bufferevent uses finalizers and
will free itself only from the loop (well this is not a problem if you
do not play games with various event_base in different threads) it
generates questions, so rewrite it in more reliable way.

Fixes: #712
2018-11-13 22:26:12 +03:00
Azat Khuzhin
26ef859aa7
Add evhttp_parse_query_str_flags()
And a set of flags:
- EVHTTP_URI_QUERY_LAST
- EVHTTP_URI_QUERY_NONCONFORMANT

Fixes: #15
2018-10-27 17:59:11 +03:00
Azat Khuzhin
b94d913d90
http: allow non RFC3986 conformant during parsing request-line (http server)
Reported-by: lsdyst@163.com
2018-10-23 00:12:03 +03:00
Azat Khuzhin
64ead341a0
http: do not try to parse request-line if we do not have enough bytes 2018-10-22 23:56:50 +03:00
Azat Khuzhin
254fbc81b4
http: allow trailing spaces (and only them) in request-line (like nginx) 2018-10-22 23:56:31 +03:00
Azat Khuzhin
6cf659b0bd
http: cleanup of the request-line parsing 2018-10-22 23:55:35 +03:00
Nathan French
514dc7579c
[http] fix C90 warnings 2018-07-05 12:46:51 -04:00
Greg Hazel
367cd9e5c2 Fix evhttp_connection_get_addr() fox incomming http connections
Install conn_address of the bufferevent on incomping http connections
(even though this is kind of subsytem violation, so let's fix it in a
simplest way and thinkg about long-term solution).

Fixes: #510
Closes: #595 (pick)
2018-04-24 02:29:17 +03:00
Azat Khuzhin
cd57e38c3f http: remove message in case !Content-Length and Connection!=close
Since [1] GET can have body, and hence for every incomming connection it
will print this error.

[1] db483e3b002b33890fc88cadd77f6fd1fccad2d2 ("Allow bodies for
GET/DELETE/OPTIONS/CONNECT")

Noticed-by: BotoX (irc)
Refs: #408
2018-02-20 12:12:19 +03:00
Azat Khuzhin
61c2149268 http: fix leaks in evhttp_uriencode()
Fixes: #584
2018-01-09 21:47:57 +03:00
John Fremlin
727bcea130 http: add callback to allow server to decline (and thereby close) incoming connections.
This is important, as otherwise clients can easily exhaust the file
descriptors available on a libevent HTTP server, which can cause
problems in other code which does not handle EMFILE well: for example,
see https://github.com/bitcoin/bitcoin/issues/11368

Closes: #578 (patch cherry picked)
2017-12-18 03:00:04 +03:00
Greg Hazel
65eb529a9f CONNECT method only takes an authority 2017-12-11 01:03:29 +03:00
Azat Khuzhin
306747e51c Fix crashing http server when callback do not reply in place from *gencb*
This is the second hunk of the first patch
5ff8eb26371c4dc56f384b2de35bea2d87814779 ("Fix crashing http server when
callback do not reply in place")

Fixes: #567
2017-11-04 19:15:32 +03:00
Azat Khuzhin
db483e3b00 Allow bodies for GET/DELETE/OPTIONS/CONNECT
I checked with nginx, and via it's lua bindings it allows body for all
this methods. Also everybody knows that some of web-servers allows body
for GET even though this is not RFC conformant.

Refs: #408
2017-10-30 11:32:13 +03:00
Andreas Gustafsson
99d0a952da Do not crash when evhttp_send_reply_start() is called after a timeout.
This fixes the crash reported in issue #509.  The "would be nice"
items discussed in #509 can be addressed separately.
2017-10-30 11:32:13 +03:00
Azat Khuzhin
5ff8eb2637 Fix crashing http server when callback do not reply in place
General http callback looks like:
  static void http_cb(struct evhttp_request *req, void *arg)
  {
    evhttp_send_reply(req, HTTP_OK, "Everything is fine", NULL);
  }

And they will work fine becuase in this case http will write request
first, and during write preparation it will disable *read callback* (in
evhttp_write_buffer()), but if we don't reply immediately, for example:
  static void http_cb(struct evhttp_request *req, void *arg)
  {
    return;
  }

This will leave connection in incorrect state, and if another request
will be written to the same connection libevent will abort with:
  [err] ../http.c: illegal connection state 7

Because it thinks that read for now is not possible, since there were no
write.

Fix this by disabling EV_READ entirely. We couldn't just reset callbacks
because this will leave EOF detection, which we don't need, since user
hasn't replied to callback yet.

Reported-by: Cory Fields <cory@coryfields.com>
2017-10-29 20:30:42 +03:00
Azat Khuzhin
da3f2ba22a fix handling of close_notify (ssl) in http with openssl bufferevents
Since it can arrive after we disabled events in that bufferevent and
reseted fd, hence evhttp_error_cb() could be called after
SSL_RECEIVED_SHUTDOWN.

Closes: #557
2017-10-22 02:01:09 +03:00
Vis Virial
db60ade81d http: do not use local settings for Date header 2016-12-19 00:55:50 +03:00
Azat Khuzhin
1cbf26f67a http: fix formatter for pritnf for req->ntoread (osx) 2016-12-06 11:51:40 +03:00
Thomas Bernard
e983712456 use ev_uint16_t instead of unsigned short for port
Like in `sockaddr_in` structure in /usr/include/netinet/in.h

@azat: convert all other users (bench, compat, ..) and tweak message
Fixes: #178
Fixes: #196
Refs: 6bf1ca78
Link: https://codereview.appspot.com/156040043/#msg4
2016-10-26 01:41:13 +03:00
Zonr Chang
c6b1ec1220 Fix evhttp_uriencode() regression.
http_uriencode_test() (in test/regress_http.c) has been failed after
72afe4c as "hello\0world" is encoded to "hello" instead of
"hello%00world". This is because of a misplaced overflow check which
causes the non-negative "size" specified in parameter being ignored in
within-bound URI.

Fixes: #392
2016-08-27 01:24:11 +03:00
Mark Ellzey
e94250c8e3
removed unused vars 2016-08-14 14:03:56 -07:00
Mark Ellzey
72afe4c93b
pointer overflow checks for evhttp_uriencode
Check to make sure pointer math is all OK.
2016-08-14 14:02:37 -07:00
Mark Ellzey
17cc636223
[Issue #313] set method to ASCII "NULL" if evhttp_method() returns NULL 2016-06-24 18:07:39 -07:00
Azat Khuzhin
24b521499a evhttp_have_expect(): fix -Wlogical-not-parentheses
../http.c:589:6: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]
        if (!req->kind == EVHTTP_REQUEST || !REQ_VERSION_ATLEAST(req, 1, 1))
                        ^          ~~
2016-03-25 10:21:48 +03:00
Azat Khuzhin
7a4b472925 http: set fd to -1 unconditioally, to avoid leaking of DNS requests
Otherwise:
http/cancel_by_host_ns_timeout_inactive_server: [msg] Nameserver 127.0.0.1:37035 has failed: request timed out.
[msg] All nameservers have failed
OK
1 tests ok.  (0 skipped)
==26211==
==26211== FILE DESCRIPTORS: 3 open at exit.
==26211== Open file descriptor 2: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211== Open file descriptor 1: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211== Open file descriptor 0: /dev/pts/47
==26211==    <inherited from parent>
==26211==
==26211==
==26211== HEAP SUMMARY:
==26211==     in use at exit: 1,112 bytes in 5 blocks
==26211==   total heap usage: 149 allocs, 144 frees, 18,826 bytes allocated
==26211==
==26211== 40 bytes in 1 blocks are indirectly lost in loss record 1 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x498F5B: evbuffer_add_cb (buffer.c:3309)
==26211==    by 0x4A0EF5: bufferevent_socket_new (bufferevent_sock.c:366)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 136 bytes in 1 blocks are indirectly lost in loss record 2 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x491FF0: evbuffer_new (buffer.c:365)
==26211==    by 0x49A1BE: bufferevent_init_common_ (bufferevent.c:300)
==26211==    by 0x4A0E44: bufferevent_socket_new (bufferevent_sock.c:353)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 136 bytes in 1 blocks are indirectly lost in loss record 3 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x491FF0: evbuffer_new (buffer.c:365)
==26211==    by 0x49A1FB: bufferevent_init_common_ (bufferevent.c:305)
==26211==    by 0x4A0E44: bufferevent_socket_new (bufferevent_sock.c:353)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 536 bytes in 1 blocks are indirectly lost in loss record 4 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x4A0E15: bufferevent_socket_new (bufferevent_sock.c:350)
==26211==    by 0x4BFADF: evhttp_connection_base_bufferevent_new (http.c:2375)
==26211==    by 0x4BFC8F: evhttp_connection_base_new (http.c:2427)
==26211==    by 0x460DAA: http_cancel_test (regress_http.c:1417)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== 1,112 (264 direct, 848 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==26211==    at 0x4C2BBD5: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26211==    by 0x4AAEB2: event_mm_calloc_ (event.c:3459)
==26211==    by 0x4D0564: evdns_getaddrinfo (evdns.c:4685)
==26211==    by 0x4B13BA: evutil_getaddrinfo_async_ (evutil.c:1575)
==26211==    by 0x4A139E: bufferevent_socket_connect_hostname (bufferevent_sock.c:524)
==26211==    by 0x4C02DB: evhttp_connection_connect_ (http.c:2588)
==26211==    by 0x4C04DD: evhttp_make_request (http.c:2643)
==26211==    by 0x4615FF: http_cancel_test (regress_http.c:1504)
==26211==    by 0x490A78: testcase_run_bare_ (tinytest.c:105)
==26211==    by 0x490D5A: testcase_run_one (tinytest.c:252)
==26211==    by 0x491699: tinytest_main (tinytest.c:434)
==26211==    by 0x47E0E0: main (regress_main.c:461)
==26211==
==26211== LEAK SUMMARY:
==26211==    definitely lost: 264 bytes in 1 blocks
==26211==    indirectly lost: 848 bytes in 4 blocks
==26211==      possibly lost: 0 bytes in 0 blocks
==26211==    still reachable: 0 bytes in 0 blocks
==26211==         suppressed: 0 bytes in 0 blocks
2016-03-24 14:01:31 +03:00
Azat Khuzhin
f0e1341179 http: avoid leaking of fd in evhttp_connection_free()
Since we do close fd there if we don't have BEV_OPT_CLOSE_ON_FREE, and
evcon->fd can be incorrect (non -1), so just get it from the underlying
bufferevent to fix this.

And after this patch the following tests report 0 instead of 2307 fd leaks:
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
==11299== FILE DESCRIPTORS: 3 open at exit.

And this is stdin/stderr/stdout.
2016-03-23 12:53:51 +03:00
Azat Khuzhin
4a53c54bf7 http: get fd from be layer during connection reset
Since it can be non -1, and we must close it, otherwise we will have problems.

And after this patch the following tests report fd 2307 instead of 2309 fd leaks:
$ valgrind --leak-check=full --show-reachable=yes --track-fds=yes --error-exitcode=1 regress --no-fork http/cancel..
==10853== FILE DESCRIPTORS: 2307 open at exit.
2016-03-23 12:53:03 +03:00
Azat Khuzhin
d4054928c7 http: make fallback for EVHTTP_CON_READ_ON_WRITE_ERROR more cleaner 2016-03-11 20:59:58 +03:00
Azat Khuzhin
2ff164abac http: fix EVHTTP_CON_READ_ON_WRITE_ERROR when it doesn't supported by OS
For example win32 doesn't accept such things (maybe via overloaded IO, I'm not
sure), also I looked into curl and seems that the behaviour is the same (IOW
like with EVHTTP_CON_READ_ON_WRITE_ERROR on linux/win32).

Fixes: https://ci.appveyor.com/project/nmathewson/libevent/build/2.1.5.216#L499 (win32)
Fixes: 680742e1665b85487f10c0ef3df021e3b8e98634 ("http: read server response
even after server closed the connection")
v2: v0 was just removing that flag, i.e. make it deprecated and set_flags() will return -1
2016-03-11 20:59:58 +03:00
Azat Khuzhin
7c8999956f http: do not do function calls under EVUTIL_ASSERT() to fix NDEBUG builds
Fixes: 2185e639210f072f37e9d19aff7dba382db84529 ("http: assert's that
evbuffer_drain() success on connection reset")
Fixes: http/data_length_constraints
  FAIL ../test/regress_http.c:3775: assert(evhttp_request_get_response_code(req) == HTTP_ENTITYTOOLARGE): 501 vs 413
2016-03-11 20:59:58 +03:00
Azat Khuzhin
8f18a626e6 http: fix leaking of response_code_line
Since now evhttp_parse_response_line() can be called twice because after
"HTTP/1.1 100 Continue" we can have "HTTP/1.1 200"

==29162== 9 bytes in 1 blocks are definitely lost in loss record 1 of 1
==29162==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29162==    by 0x5CBF0A9: strdup (in /lib/x86_64-linux-gnu/libc-2.21.so)
==29162==    by 0x4AA3AC: event_mm_strdup_ (event.c:3493)
==29162==    by 0x4BD843: evhttp_parse_response_line (http.c:1680)
==29162==    by 0x4BE333: evhttp_parse_firstline_ (http.c:2013)
==29162==    by 0x4BEA4F: evhttp_read_firstline (http.c:2243)
==29162==    by 0x4BC5F8: evhttp_read_cb (http.c:1136)
==29162==    by 0x4993F1: bufferevent_run_readcb_ (bufferevent.c:233)
==29162==    by 0x49FBC0: bufferevent_trigger_nolock_ (bufferevent-internal.h:392)
==29162==    by 0x49FF10: bufferevent_readcb (bufferevent_sock.c:208)
==29162==    by 0x4A474A: event_persist_closure (event.c:1580)
==29162==    by 0x4A49F5: event_process_active_single_queue (event.c:1639)

Fixes: 0b46b39e95ad77951176f09782138305ba34edf3 ("http: fix "Expect:
100-continue" client side")
2016-03-11 20:59:12 +03:00
Azat Khuzhin
0b46b39e95 http: fix "Expect: 100-continue" client side
Instead of sending data always at the beginning of the request wait until the
server will respond with "HTTP/1.1 100 Continue".
Before this patch server do send "HTTP/1.1 100 Continue" but client always send
post data even without waiting server response.

P.S. this patch also touches some not 100% related tab-align issues.

Covered-by: http/data_length_constraints
Covered-by: http/read_on_write_error
2016-03-11 20:58:46 +03:00
Azat Khuzhin
2185e63921 http: assert's that evbuffer_drain() success on connection reset
Since otherwise we can have nasty bugs with part of previous *request* in
current *request* and hence some parsing errors.

And now we have failures:
  http/non_lingering_close: [forking] [err] ../http.c:1326: Assertion !evbuffer_drain(tmp, -1) failed in ../http.c
2016-03-11 18:53:10 +03:00
Azat Khuzhin
ac448a74d0 http: take EVHTTP_CON_LINGERING_CLOSE into account for "Expect: 100-Continue"
Also since after this patch code became more generic, we now respond with
HTTP_ENTITYTOOLARGE even without "Expect: 100-Continue", which is correct by
RFC.

Refs: #321
v2: remove EVHTTP_CON_ABOUT_TO_CLOSE
2016-03-09 18:52:52 +03:00