| Date | Commit message (Collapse) |
|---|
|
This is meant to provide an easy starting point for server admins.
It provides a basic HTTP server for admins unfamiliar with
configuring PSGI applications as well as being an identical
interface for management as our nntpd implementation.
This HTTP server may also be a generic Plack/PSGI server for
existing Plack/PSGI applications.
|
|
We can avoid making getpeername syscalls this way.
|
|
Hopefully this gives new hackers a better overview of
how the components relate to each other.
|
|
Ensure we are executable for consistency and documentation.
MakeMaker already makes this executable, but we might as
well do the same...
|
|
The document data of a search message already contains a good chunk
of the information needed to respond to OVER/XOVER commands quickly.
Expand on that and use the document data to implement OVER/XOVER
quickly.
This adds a dependency on Xapian being available for nntpd usage,
but is probably alright since nntpd is esoteric enough that anybody
willing to run nntpd will also want search functionality offered
by Xapian.
This also speeds up XHDR/HDR with the To: and Cc: headers and
:bytes/:lines article metadata used by some clients for header
displays and marking messages as read/unread.
|
|
We cannot avoid requiring ::Config, so do not hide it.
|
|
It doesn't actually give performance improvements unless we
use types with "my", but we don't do that. We'll only continue
using fields with Danga::Socket-derived classes where they're
required.
|
|
We'll probably be supporting read-only IMAP, or maybe
we'll just implement a custom HTTP server so users can
manage/upgrade the same way as the nntpd while being
immune to slow clients.
|
|
We may support SIGUSR2 in single-process mode as long
as permissions aren't wonky.
|
|
We can use the UNIVERSAL::can to better encapsulate the shutdown
process, in case we need to implement a gopher or HTTP daemon.
|
|
This is better encapsulated and hopefully more readable.
While we're at it, check for being inside a long response, too.
|
|
We don't want clients hogging server resources and preventing
us from shutting down, so give them 30s to finish whatever
request they're getting.
|
|
This should fully support the signals used by nginx and starman,
so scripts used by nginx can be used to manage our nntpd daemon,
too.
|
|
Apparently, my mental model of Perl internals is still incorrect
after all these years. I am but a simple *nix programmer:
everything is a bag of bytes to me.
This fixes a problem with UTF-8 headers from Xapian (via
"XHDR Subject [range]") triggering partial writes and writing an
extra newline to the outputs.
|
|
Using non-hierarchical mailing list names for newsgroups
might confuse traditional newsreader software and perhaps
some humans. Allow administrators to configure newsgroups
names and hierarchies to their liking.
Sorting the grouplist alphabetically should probably be
done anyways to improve usability for some clients which
won't sort themselves.
|
|
We cannot use the push_back_read functionality of Danga::Socket
since it will trigger event_read on buffered data. This would
allow a malicious (or badly implemented) client to burn CPU
without actually sending us anything.
So we still do buffering ourselves and play some tricks with
timers re-enable readability.
|
|
Avoid depending on IO::Socket::INET if we can help it,
we do not need to bloat ourselves with lot of that
functionality.
|
|
This will allow us to redirect stdout/stderr more easily
for logging.
|
|
Implementing NEWNEWS, XHDR, XOVER efficiently will require
additional caching on top of msgmap.
This seems to work with lynx and slrnpull, haven't tried clients.
DO NOT run in production, yet, denial-of-service vulnerabilities
await!
|