Date | Commit message (Collapse) |
|
Address::names is sufficient to handle what from_name did.
|
|
Favor Inbox objects as our primary source of truth to simplify
our code. This increases our coupling with PSGI to make it
easier to write tests in the future.
A lot of this code was originally designed to be usable
standalone without PSGI or CGI at all; but that might increase
development effort.
|
|
We'll be switching to a getline/close response body
to give the HTTP server more control when dealing
with slow clients.
|
|
We overuse streaming, here. Allow Content-Length to be
calculated in this case.
|
|
This will eventually allow us to reuse code to generate a common
header.
|
|
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 :<
|