| Date | Commit message (Collapse) |
|---|
|
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!
|