| Date | Commit message (Collapse) |
|---|
|
We handle encoding-related things elsewhere.
|
|
Message-IDs should not be MIME encoded, but in case they are,
use the raw form for compatibility with ssoma and possibly
other tools. This prevents a potential problem where a
malicious client could confuse our storage layer into indexing
incorrect contents.
|
|
We can rely on timely auto-destruction based on reference
counting; reducing the chance of redundant close(2) calls
which may hit the wront FD.
We do care about certain close calls (e.g. writing to a buffered
IO handle) if we require error-checking for write-integrity. In
other cases, let things go out-of-scope so it can be freed
automatically after use.
|
|
Relying on Plack::Handler::CGI is much easier for long-term
maintenance and development.
Nowadays, we even include our own httpd implementation to
facilitate easier deployment with PSGI/Plack.
|
|
Normal browsers should understand relative path names.
Atom feeds may be hosted externally and seems to need
full URLs.
|
|
It seems we need to declare "alternate" and "text/html" at least
for feed readers.
|
|
We'll probably want to continue supporting CGI for mod_perl
compatibility.
|
|
While having the extra " feed" is noisy in the main topic
landing page, it is useful in headers/footers which have
plenty of space to be more descriptive.
|
|
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.
|
|
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.
|
|
User-generated content (UGC) may have excessively long lines
which screw up rendering. This is the only bit of CSS we use.
|
|
Hopefully this gives new hackers a better overview of
how the components relate to each other.
|
|
This is the official name of the spec, so refer to it
as such despite the file extension being lower-cased
|
|
This can be helpful for folks who want to subscribe
to a particular topic or keyword.
|
|
We'll be reusing this code further in the next commit.
|
|
In the future, it should be possible to use this:
git ls-files | UPDATE_COPYRIGHT_HOLDER='all contributors' \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
xargs /path/to/gnulib/build-aux/update-copyright
|
|
This hopefully makes it easier to find things without resorting
to proprietary external services.
|
|
This lets us merge topics with different subjects with a common parent
(common in "[PATCH 0/X]" threads). This also lets us avoid forking for
the HTML index page, too.
|
|
This is the correct Content-Type for Atom feeds, especially
since we updated to use ".atom" as the suffix.
|
|
Provide a fallback for legacy SHA-1 messages, but do not
advertise shorter URLs anymore for data portability concerns.
This fixes a regression introduced in
commit 81a9c1b476987d845b340ab9013d26cf4487cb9a
("search: disable Message-ID compression in Xapian")
which ended up breaking thread-related endpoints for
large Message-IDs, as lookups on the SHA-1 message no longer
worked.
|
|
It makes sense to distinguish the two a little.
|
|
Fixes commit d44ed46ee92c78aaaed64975c4d6846613963be4
("implement per-thread Atom feeds")
|
|
This allows common /m/ links to be used without a prefix,
saving 2 precious bytes for permalinks and raw messages.
Old URLs continue to redirect.
|
|
The MIME type entry for Atom feed relies on "atom",
so allow properly-configured static file servers to serve
it with the correct Content-Type header.
|
|
This allows users to subscribe to only a single thread
with their feed reader without subscribing to the rest of
the thread.
Update our endpoint notes while we're at it.
|
|
We'll be using it for per-thread subscriptions
|
|
This will hopefully make life easier for feed readers.
|
|
Perl does not currently optimize for this.
ref (from p5p):
http://mid.gmane.org/D5C27970-9176-4C7A-8B99-7D78360E67A2@pobox.com
|
|
These URLs are preferable in case somebody decides to get cute and
use a suffix we would've used to prevent others from linking to
their message. The common /m/$MESSAGE_ID/ URLs are now 4 characters
shorter so may fit better on terminals.
|
|
This fixes a regression introduced in
commit 72c0f7c71ff28de9755dc4aee8b6ce6f0e4f2ed7
(feed: merge subjects regardless of "[PATCH vN]")
|
|
This normalizes rerolled patches with identical topics,
but does not normalize different patches even if they are
in the same thread (for now).
|
|
Consistently name mid_* functions as verbs.
|
|
Using hash means we no longer have to document and remember what
every field does. The original array form was insane premature
optimization and crazy. Who wrote that? Oh wait, I was on
drugs :<
|
|
Email::Address::name never fails assuming it was able to parse
anything.
|
|
public-inbox git repositories require a "HEAD" ref to
function correctly anyways.
|
|
We will attempt to generate Atom feeds "by hand" as the
XML::Atom::SimpleFeed API does not support streaming output.
Since email is large and servers are small, this should prevent
wasting memory when we generate larger feeds.
Of course, we hope clients use SAX parsers capable of handling
large streams without slurping.
|
|
This should allow progressive rendering on the client and reduce
memory usage on the server. Unfortunately XML::Atom::SimpleFeed
does not yet support streaming, so we may not use it in the
future.
|
|
Oops!
|
|
This is for consistency with ssoma. I doubt it makes
a difference in practice, but in case somebody decides
any of the Message-ID-containing headers should have
strange characters, we'll decode and attempt to thread
them. This isn't an attack vector, just a way to
make messages thread improperly which is pointless...
|
|
Add some spacing between topics to improve readability when
scanning or in case a subject gets too long.
The title and Atom feed may not be highly-visible otherwise.
While we're at it, use the proper "Atom feed" terminology since
some folks may not understand just what "atom" means.
|
|
We can display /t/$MESSAGE_ID.html easily with a Xapian search
index, so rely on it instead of trying to display messages inline.
|
|
This is more space efficient since we don't need to place padding
bytes in front of every line. While this unfortunately does not
render well on lynx; w3m, links, elinks can all render tables
sanely.
Tables are also superior for long lines which require wrapping
inside <pre> containers.
|
|
We don't need share duplicate logic across both files.
|
|
We'll be making the index smarter for people with search
support enabled. Otherwise, it'll be chronological and
a bit dumb. At least it'll use less memory.
|
|
We can rely on reference counting to lower memory usage for
big messages.
|
|
No need to waste bandwidth, here
|
|
No need to create a new hash when we can reuse the existing one
more.
|
|
/t/ always falls back to subject path searching anyways,
so there's little lost besides perhaps more readable URLs.
Unfortunately people still use non-compliant mail clients which fail
to set In-Reply-To or References headers :<
|
|
We no longer do "smart" time displays as of
commit ea0e8649f90d1fd0850a41c0ca16642faadf4f14
("view: simplify timestamp generation").
In retrospect, that commit also made us more cache-friendly, too.
|
|
We'll be sharing the same threading, so it makes sense to sort
replies using the same code and message headers without repeating
ourselves.
This also standardizes on sorting on X-PI-TS (Unix epoch in seconds)
instead over using X-PI-Date differently in two different places
|