| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Prevent Bad Things from happening when the buffer gets full.
This of course opens up the possibility of intentionally killing
connections by sending much stuff, which need to be mitigated with rate
limits elsewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: The string slice operations when a lot of data gets buffered
ends up being expensive and memory-consuming. We have util.dbuffer for
precisely this kind of thing.
I want to keep the behavior of writebuffer being upgraded from nil to a
string to full buffer since the last step involves three table
allocations, where the previous buffer method only used one. Avoiding
those allocations for simple writes like white space keep alive feels
like it would keep memory churn down.
This work was started in 2020
|
|
|
|
| |
Continuation of 4b39691a274e
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Prevents the mistake of creating a http context without any TLS context
and then trying to use HTTPS, which doesn't work right.
Thanks nils
|
| |
| |
| |
| | |
Simplifies shipping well-known DH parameters in the config
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enables accepting admin stream socket (UNIX) connections trough the
same procedures as any other (TCP) socket, which avoids problems caused
by using the wrapclient API, which ends up discarding early data due to
only expecting early connection failure.
Fixes #1867
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows creating listening sockets and accepting client connections
before Prosody starts.
This is unlike normal Prosody dynamic resource management, where ports
may added and removed at any time, and the ports defined by the config.
Weird things happen if these are closed (e.g. due to reload) so here we
prevent closing and ensure sockets are reused when opened again.
|
| |
| |
| |
| |
| |
| |
| | |
libunbound does not tell us the whole chain of CNAMEs, only the final
canonical name.
This is to aid in debugging since it will only be shown in the shell.
|
| |
| |
| |
| | |
Reverts 4a9a69659727
|
| | |
|
| |
| |
| |
| | |
To aid in tracking down signalfd-related problems
|
| |
| |
| |
| | |
To make any such failures noticeable
|
|\| |
|
| |
| |
| |
| | |
Fixes error in #1765 by throwing an error earlier
|
| | |
|
| |
| |
| |
| |
| |
| | |
Handling signal events the same way as all other events makes sense and
seems safer than the signal handling just jumping around in C and
messing with Lua states.
|
| |
| |
| |
| | |
Unclear why this would be done, but an error is not great.
|
| | |
|
|\| |
|
| |
| |
| |
| | |
This case would eventually be rejected by the buffer size limit.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise requests with Connection: close would be stuck in the async
wait that starts after the handle_request() call.
Together with the new async debugging, this makes the async thread stay
in the set of waiting runners forever, where previously it would simply
be garbage collected.
|
| |
| |
| |
| | |
Should skip a syscall for each write when using epoll.
|
| |
| |
| |
| | |
Connection: keep-alive is implicit in HTTP/1.1 but explicit > implicit
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This should speed up repeated requests to the same site by keeping their
connections around and sending more requests on them.
Sending multiple requests at the same time is not supported, instead a
request started while another to the same authority is in progress would
open a new one and the first one to complete would go back in the pool.
This could be investigated in the future.
Some http servers limit the number of requests per connection and this
is not tested and could cause one request to fail, but hopefully it will
close the connection and prevent it from being reused.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
mod_http_errors normally sets the Content-Type header via the response
object, which isn't available when handling these uncaught errors.
Without a Content-Type header the browser is forced to guess, which may
or may not result in something sensible.
|
| |
| |
| |
| | |
The XOR is done in C since 4e5a2af9dd19
|
| |
| |
| |
| |
| | |
server_select only depending on LuaSocket generally makes it more
portable, so fall back to that if util.poll can't be found.
|
| |
| |
| |
| | |
Eases locating the request in logs
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Since these are noisy and we have the thing in util.helpers to log
events fired.
The new status line events are meant to replace these as they include
more useful info.
|
| |
| |
| |
| | |
Points out the beginning and end of a request.
|
| | |
|
| |
| |
| |
| |
| | |
Goal is improve tracking of individual HTTP requests throughout its
life-cycle. Having a single ID to use in logging should help here.
|
| | |
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This information is sometimes necessary in the context where we have a
connection that we know (or believe to be) associated with an incoming HTTP
request.
For example, it can be used to retrieve the IP address of a request (which may
differ from the IP address of the connection, due to X-Forwarded-For and co).
Thanks to the Jitsi team for highlighting this gap in the API.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
This ensures that we support responses without a content-length header, and
allow streaming them through the streaming handler interface. An example of
such a response would be Server-Sent Events streams.
|
| | |
|
| |
| |
| |
| |
| | |
Frees unneeded resources earlier, so they're not held on to while
potentially sending the chunk trailer.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unregistering the response before sending the trailer of the chunked
transfer encoding prevents opportunistic writes from being invoked and
running this code again when, which may cause an error when closing the
file handle a second time.
Normally the file size is known, so no chuck headers are sent.
|
| |
| |
| |
| |
| |
| |
| | |
Main difference is that timers are not checked unconditionally before
each poll, only when running out of previous poll results (hidden by
util.poll). This removes a final poll at shutdown that usually delays
the 'not quitting' condition check by one second.
|
| |
| |
| |
| |
| | |
This isn't actually used in Prosody, so no value in complicating the
real main loop because of it
|