| Date | Commit message (Collapse) |
|---|
|
If we bite the bullet and rely on inline CSS, we might as well
only specify it once per page instead of inline in every <pre>
tag which may handle UGC. So this actually saves us a small
amount of bandwith on most pages which have multiple <pre>
start tags.
|
|
HTTP/1.1 clients will want persistent connections and
need to know response terminations.
|
|
Ghost message links didn't show up too well after
commit bc067a7562a586bed92401fe1084bbe423b9451a
("view: move thread info near top of single view")
Additionally, attribution lacked a space when subjects changed
mid-thread.
|
|
Fixes commit 4c2c2325d2948ec5340e2fcafbee798cf568f5fd
("rename 'GitCatFile' package to 'Git'")
|
|
Most framed mail viewing software has message ancestry
information near the top instead of bottom (mutt, gmane,
sylpheed, thunderbird) as it can help improve context.
Traditional netiquette also favors writing replies below
quoted (older) text for this reason; so move the thread
summary to the top of the message for context.
Since threads may be long, add a "skip" anchor link to jump to
the message body quickly, and align the date to the left column
so it's easier to tell the relative age of messages.
While we're at it, remove quotes from "id" attributes to
improve ease-of-grep-ability.
|
|
Users may be iterating through lists and come up with nothing
|
|
We'll be using it for more than just cat-file.
Adding a `popen' API for internal use allows us to save a bunch
of code in other places.
|
|
The "cat_file" sub now allows a block to be passed for partial
processing. Additionally, a new "check" method is added to
retrieve only object metadata: (SHA-1 identifier, type, size)
|
|
User-generated content (UGC) may have excessively long lines
which screw up rendering. This is the only bit of CSS we use.
|
|
These will be reused elsewhere.
|
|
Sometimes users (me :x) blindly append "raw" to a /t/ URL...
|
|
Avoid truncating messages if we requested the root anchor.
This regression appeared in
commit 62ee3cb36dd08f17e444e96dc80108464ee10cba
("view: do not shorten top-level messages in thread view")
Also, make the "More..." link more prominent, as readers
should be made aware they're not reading the full message.
|
|
Avoid the visual noise entirely by using a space instead.
I sometimes have difficulty distinguishing '0' from '8' while
other users may mistake it for an 'O' character. Most digital
clocks I've seen will omit displaying a leading zero for the
hour, too.
This may also save transfer time by allowing better compression
(since there is a space between the date and time anyways) and
perhaps reduce client rendering time on some displays.
We'll leave the leading zero for minutes since that seems pretty
standard for digital clocks.
|
|
It's potentially unsafe (leading to hidden messages) at any level.
|
|
Just because a message is currently alone does not mean
the links won't be valid in the future when more messages
show up.
|
|
Unlinked threads with similar (but not identical) subjects
could be hidden as a result.
|
|
Apparently git allows them, and they're definitely alright
in email addresses.
|
|
Hopefully this gives new hackers a better overview of
how the components relate to each other.
|
|
Error messages and request lines may contain '%' which would
throw off Perl printf.
|
|
This is the official name of the spec, so refer to it
as such despite the file extension being lower-cased
|
|
The "by" on the message page and "-" in the index are
unnecessary and readers should have no trouble figuring out
what the attribution/timestamp line means.
|
|
Of course, we need to figure out if RFC 4685 is supported anywhere,
first.
|
|
They increase HTML size and add to visual noise without telling
enough useful information.
|
|
Improve error messages and use a better regexp for detecting
printable characters in attachments.
|
|
Oops, there is no longer a 3rd element.
Fixes: 759efc037728a766ee80f1b0d3c1fd7b8c76a05f
("view: remove attribution for topics in top-level view")
|
|
It clutters up the page unnecessarily, as identity of the topic
starter/updater probably doesn't matter if there's no exact
message to attribute the message to.
|
|
Network connections may use OpenSSL for TLS (as other libraries,
such as GNUTLS do not appear well-supported under Perl). So
give this exception in case somebody needs TLS support for NNTP.
|
|
Downloaded mboxen can be archived/stored indefinitely, try to
make it easy for future archaelogists to find the online
archive location.
|
|
It may be present in messages imported from NNTP.
|
|
Having per-thread Atom feeds and downloadable mboxen is powerful
and should be more easily visible/accessible to casual readers.
|
|
For list where we are not the primary archival entry point,
defaulting to filter=scrub makes sense since their list
conventions may be more tolerant of HTML and other crap
than we are.
|
|
Xapian has this limit for terms, and there are likely no
legitimate Message-IDs (or single header lines) this long; so
there's no need to workaround this limit.
|
|
We use it as a general compressor for identifiers such as
subject paths, so using the "mid_" prefix probably is not
appropriate.
|
|
Ensure we are executable for consistency and documentation.
MakeMaker already makes this executable, but we might as
well do the same...
|
|
This doesn't seem to do anything on my older system, but maybe it
will in newer or future versions of DBD::SQLite. Anyways it can
be helpful for documentation purposes, too.
|
|
Sometimes subjects are excessively long and hit Xapian's 245-byte
term limit. We can still perform subject-only searches with
a probabilistic prefix.
|
|
It may be hard to tell what command triggered an error,
otherwise.
|
|
Oops
|
|
We don't want to waste precious server memory on clients which
have been idle for longer than 3 minutes.
|
|
While we're at it, reject non-plain-text top-level messages,
too. They probably do not exist in practice, but we cannot
afford to scrub given policies implemented by overzealous
mail providers.
While we're at it, update the comment for strip_multipart.
|
|
Oops, I forgot to run the syntax check for this.
|
|
It's often part of idiotic policies to prevent mailing lists
from working at all.
|
|
This is probably unsafe
|
|
The last message in a thread _display_ is not necessarily the
latest message in the thread. We must go by the Date: header
on the messages themselves as a best-guess. Of course Date:
headers may lie, but most mail clients trust them by default,
so we will, too.
|
|
That's right, we now have our NNTP server running and are
self-hosting a read-only news gateway at:
nntp://news.public-inbox.org/inbox.comp.mail.public-inbox.meta
|
|
'+' is more shoter and more readable in query parameters than '%20'
|
|
More testing is good, especially since clients I use
don't implement all the commands.
|
|
Multiline responses must end with "\r\n.\r\n", so we won't
break out early in case the OS doesn't support MSG_MORE.
|
|
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 shall remove slow, unoptimized headers in XHDR/HDR to avoid
becoming an easy DoS target.
|