| Date | Commit message (Collapse) |
|---|
|
Still a work in progress, but SearchView no longer depends
on Plack::Request at all and Feed is getting there.
We now parse all query parameters up front, but we may do
that lazily again in the future.
|
|
git has stricter requirements for ident names (no '<>')
which Email::Address allows.
Even in 1.908, Email::Address also has an incomplete fix for
CVE-2015-7686 with a DoS-able regexp for comments. Since we
don't care for or need all the RFC compliance of Email::Address,
avoiding it entirely may be preferable.
Email::Address will still be installed as a requirement for
Email::MIME, but it is only used by the
Email::MIME::header_str_set which we do not use
|
|
This hopefully makes the intent of the code clearer, too.
The the HTTP use of the numeric reference for getline
caused problems in Git.pm, already.
|
|
This can be useful for lists where the convention is to
attach (rather than inline) patches into the message body.
|
|
Remove unnecessary wrapper subroutines and constants
which are only used once.
|
|
We try to avoid issues like these by using relative URLs
in hrefs, but we can't avoid the problem with Location:
for redirects and Atom feeds which are likely to be
rehosted elsewhere.
We also reorder some of the code to work around a weird
issue on the psgi-plack mailing list:
<20160516073750.GA11931@dcvr.yhbt.net>
(Somewhere on https://groups.google.com/group/psgi-plack
but it's probably not bookmarkable)
|
|
A public-inbox is NOT necessarily a mailing list, but it
could serve as an input point for zero, one, or infinite
mailing lists :D
|
|
This can makes navigation easier with some browsers or
or browser extensions.
ref: https://www.w3.org/TR/html/links.html#sequential-link-types
|
|
Quote-folding can be detrimental as it fails to hide the
real problem of over-quoting.
Over-quoting wastes bandwidth and space for all readers, not
just WWW readers of the public-inbox. So hopefully removing
quote-folding support from the WWW interface can shame those
repliers into quoting only relevant portions of what they reply
to.
|
|
Reduce stack depth of arguments and rely more on state hashref
to store response state. We may end up shoving everything
in ctx eventually.
|
|
Ugh...
Fixes: 476fc666c223 (reduce "PublicInbox::Hval->new_oneline" use)
|
|
It's probably a bad idea to strip extraneous whitespace
from some headers as an extra space may convey useful
information.
Newlines don't seem to be preserved by Email::MIME or
Email::Simple anyways, so there's no danger in breaking
formatting.
|
|
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!
|