* Remove ssl_error_want_reuse_buffer for SSL_read:
Although the manual states we have to use the same arguments in the
next call after SSL_ERROR_WANT_*, it has been running without this
in 1.5 for a long time now.
* As POST-data chunks get copied to the next queue, we reuse chunks
there as well.
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2710 152afb58-edef-0310-8abb-c4023f1b3aa9
* This patch may "break" some configs, if they do stupid things. Like setting
ssl.pemfile to a not existing file in a "non-socket/non-ssl" block.
Fix them! :)
From: Peter Colberg <email@example.com>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2648 152afb58-edef-0310-8abb-c4023f1b3aa9
Fix linger-on-close behaviour to avoid rare failure conditions.
- Don't assume that when FIONREAD returns 0, that it's safe to close the
socket. There may still be data that's about to arrive, and we'll still
send an RST if the socket is confused, potentially confusing the client.
- Don't close the connection immediately after sending a successful
response; linger-on-close was only happening in the case of errors, but it
has to happen in case of success too, because the client doesn't
necessarily know we're about to close after this request, and may have
sent additional ones. (eg. if server.max-keep-alive-requests is small.)
- Don't close the connection immediately even if keep_alive is 0; there are
several reasons keep_alive can be 0. If the client requested Connection:
close, then it would be okay to close right away, since we can assume he
didn't send anything else. But it's harmless (and more resilient) to do
the lingering regardless.
- Increase the lingering timeout from 1s to 30s. In the vast majority of
cases, the timeout never kicks in anyway. The only times when it might
be needed are a) in race conditions, in which case timing out too early
defeats the purpose of lingering at all; b) if there's a lot of data,
which is basically the same as (a); or c) if the remote end disappears,
in which case we now suffer through a longer timeout... but we would
anyway, if we were waiting for them to receive our transmission.
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2636 152afb58-edef-0310-8abb-c4023f1b3aa9
- Use const void* in instead of unsigned char* in MD5_Update
(same as in the openssl api, to avoid signed/unsigned char* warnings)
- Add const to some pointers in md5.c
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2165 152afb58-edef-0310-8abb-c4023f1b3aa9
- do not touch if it is a HEAD request (but set file_finished)
- body gets removed for req method OPTION and some status codes
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2098 152afb58-edef-0310-8abb-c4023f1b3aa9
Fix #1324: req-method OPTIONS: do not insert default response if request was denied
- Request is handled as denied if status != 0 && status != 200
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2086 152afb58-edef-0310-8abb-c4023f1b3aa9
only run into the 404 handler if we are in direct connection mode.
that way we cant run into the 404 handler if a fastcgi app returned a
This is a small backwards incompatible change as now the *cgi app has
to generate the content for the 404 itself instead of falling back
into the 404-handler.
There is still a problem with subrequest which go back to the same
module (fastcgi app triggers subrequest which hits the fastcgi module
again) but that would require bigger changes to the plugin api. ATM
each plugin deinitialize its data after it handled the request. So the
module isnt initialized for the connection anymore and the subrequest
directly jumps out of the handler.
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@1904 152afb58-edef-0310-8abb-c4023f1b3aa9
- dont restore the http status code unconditionally (1270)
- mod_staticfile should set the http status properly. otherwise we run into
the 404 handling twice and it appends the default 404 page to the content.
(this passed the testsuite)
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@1899 152afb58-edef-0310-8abb-c4023f1b3aa9
connection and keeps trying to read from the died connection. lighttpd still responses
to other requests, it just eats up all the cpu trying to handle the died connection.
this commit fixes that problem
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@1473 152afb58-edef-0310-8abb-c4023f1b3aa9
have content on a HEAD request, take it as the
Content-Length and discard the content (as it is
a HEAD request)
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@1385 152afb58-edef-0310-8abb-c4023f1b3aa9