| Date | Commit message (Collapse) |
|---|
|
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.
|
|
Oops, we need to test commands more closely :x
Add a missing prototype while we're at it for extra
checking.
|
|
This is similar to XHDR, but differs in how it handles Message-ID
lookups.
|
|
This is allowed by RFC 2980 and HDR (to-be-implemented) in
RFC 3977 supports it, too.
|
|
We'll require some modifications for HDR support, though.
|
|
This is just like the XOVER command, but allows a single Message-ID
to be given.
|
|
These are internal metadata should be calculated, so avoid
leaking it into the header.
|
|
It's common for mail bodies to end with LF-only, so end them with
CRLF to avoid triggering errors in clients.
|
|
RFC 3977 supports YYYYMMDD dates while retaining backwards
compatibility for old YYMMDD dates.
|
|
We need to run the syscall before testing for its failure :x
|
|
RFC 3977 stipulates the use of UTF-8 as the default charset,
so we shall try using that and hopefully not mangle things.
|
|
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.
|
|
The created socket FD number may not be 3 in the test,
force it to be so inside the child process.
|
|
Reserializing the message to a string to check size wastes
considerable time and should be able to get by with slightly
less accuracy.
|
|
We could also start displaying Xref in XOVER as rtin seems to
prefer it. Anyways this is nearly 100 times faster now and
requires no DB changes.
|
|
This doesn't actually change anything as the constant is still
usable in other subroutines, but helps with consistency and
readability IMHO.
|
|
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.
|
|
public-inboxen may be aliased to multiple email addresses,
and we have always favored the first.
|
|
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.
|
|
Long responses may leave the buffer momentarily empty,
but we must prevent read events from firing at that point.
|
|
Avoid depending on IO::Socket::INET if we can help it,
we do not need to bloat ourselves with lot of that
functionality.
|
|
Lynx seems to rely on this behavior for "ARTICLE <message-id>"
Tested with Lynx Version 2.8.8dev.12 (22 Feb 2012) on Debian wheezy.
|
|
This will allow us to redirect stdout/stderr more easily
for logging.
|
|
Article number is optional, but we need to update the
article number of the client connection if it was specified
(but not if it was given a Message-ID) as stipulated by
RFC 977
|
|
It's misleading to show short times on long responses.
Instead, show the long response as a separate entry on
completion or failure.
|
|
This may be helpful for sorting out duplicates.
|
|
Using Xapian allows us to implement XROVER without forking
new processes.
|
|
We can use our msgmap database to implement "XHDR Message-ID [range]"
commands quickly. This helps immensely with slrnpull, which prefers
XHDR to LISTGROUP for some reason...
|
|
XOVER uses the current article if no range is given as
stipulated in RFC 2980.
|
|
Validate commands to make sure we do not accidentally screw up
some things or leave out some argument checking.
|
|
LISTGROUP can be expensive for giant groups, too. Use the
long response API to improve fairness and prevent excessive
buffering.
|
|
XOVER, NEWNEWS, XHDR responses may be arbitrarily long and cause
memory usage via buffering. This problem would exist even if we
were to optimize them by caching headers for fast retrieval and
search.
Introduce a generic API to handle all of these commands fairly
without triggering excessive buffering and unfairness of the
existing implementation.
Generating these responses is still expensive for now, but at least
the implementation is fair to other clients and prevents one client
from using one of these commands to monopolize resources away from
other clients.
|
|
It is shorter code and probably faster than checking an
array.
|
|
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!
|
|
The thread root is usually the most important, and should
be displayed in full.
|
|
public-inbox has search functionality, so take advantage of
good commit messages with proper titles to lookup discussion.
|
|
They're optional, but probably highly useful.
|
|
DBI + DBD::SQLite has much better handling of prefix lookups
than Xapian. While we're at it, avoid linking blatantly wrong
Message-IDs to external services.
|
|
We can avoid duplicating work of extracting messages from git if we
tie this to Xapian. Of course, this ties the two features together,
but it's probably reasonable to expect that anybody who wants to use
public-inbox to serve messages to front-end users will have both.
|
|
We'll be reusing this for loading msgmap.
|
|
This will allow us to maintain stable article numbers for an
NNTP server independently of Xapian.
|
|
Atom feeds only make sense when sorted by time, not when our
search indexing rules change and affect relevance. So do not
include the relevance option when linking to Atom feeds.
However, we shall still honor the 'r' query parameter in case
somebody wants to manually include that in the URL for
testing/experimental purposes. We simply will not advertise
it.
|
|
Otherwise it could be a bit disorienting to jump to the
first message in the thread without navigation context.
|
|
It's a waste of space and potentially confusing.
|
|
Email::MIME will call the header_obj each time anyways, avoid
the extra method lookups and hit header_obj directly for the
header lookup.
|
|
It might be helpful if user agents do not display the <link>
element in <head>.
|
|
Some user agents will advertise the presence of a feed this
way for users to subscribe to individual topics.
|
|
This can be helpful for folks who want to subscribe
to a particular topic or keyword.
|