| 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
|
|
The offset argument must be an integer for Xapian,
however users (or bots) type the darndest things.
AFAIK this has no security implications besides triggering
a warning (which could lead to out-of-space-errors)
|
|
Broken threads should be exposed to hopefully encourage people to
use proper mail clients which set In-Reply-To headers.
|
|
ref: https://www.w3.org/TR/html/links.html#sequential-link-types
Followup-to: c4183f56aab6 ("www: add rel=next and rel=prev navigation hints")
|
|
Oops. While we're at it, simplify the calls to do threading
slightly by reducing the places where we touch Mail::Thread
globals.
Fixes: 56164afc2034 (view: allow topics to be "bumped" by new replies)
|
|
Reduce stack depth of arguments and rely more on state hashref
to store response state. We may end up shoving everything
in ctx eventually.
|
|
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.
|
|
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.
|
|
This allows users to avoid HTTPS -> HTTP downgrade warnings,
but we will also avoid encouraging them towards HTTPS, for now.
IMHO: the CA system gives a false sense of security,
TLS libraries (e.g. OpenSSL) can introduce new bugs and
problems (even to attack clients), and TLS libraries
also eats memory on cheap servers.
|
|
Not needed, but this is good documentation. Some of these values
should never have newlines.
|
|
The threaded search view is somewhat alien to new users,
so ensure we label the word "relevance" for them.
|
|
Oops, the rarely-accessed threaded search view was completely
broken. Additionally, the normal threading depths were broken
when we attempted to go up-thread and replies got nested
improperly
Followup to commit be984ce279776d4513b4ca1bff05ebecafdd1bad
("view: thread using <ul> instead of <table>")
|
|
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.
|
|
Oops, we've had this forever and we also lacked a space
between the this was noticed while adding an extra
line between the "Search results ordered by" header
and actual messages.
|
|
Oops :x We need better testing...
Fixes: commit 4c2c2325d2948ec5340e2fcafbee798cf568f5fd
("rename 'GitCatFile' package to 'Git'")
|
|
Fixes: commit 398e29344ecc43548a7d3998bb5d2fcee62d66cd
("view: favor whitespace wrap in <head>")
Oops.
|
|
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.
|
|
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.
|
|
Hopefully this gives new hackers a better overview of
how the components relate to each other.
|
|
Oops, I forgot to run the syntax check for this.
|
|
It doesn't actually give performance improvements unless we
use types with "my", but we don't do that. We'll only continue
using fields with Danga::Socket-derived classes where they're
required.
|
|
Atom feeds only make sense when sorted by time, not when our
search indexing rules change and affect relevance. So do not
include the relevance option when linking to Atom feeds.
However, we shall still honor the 'r' query parameter in case
somebody wants to manually include that in the URL for
testing/experimental purposes. We simply will not advertise
it.
|
|
This can be helpful for folks who want to subscribe
to a particular topic or keyword.
|
|
This hopefully makes it easy to perform queries to display
an entire thread. Raise the limit in the threaded view to
display more results and hopefully improve the output of
thread display.
|
|
We'll be expanding the search view to handle expanded views.
|
|
The permalink should load faster if the user had a good query
and users can easily find the rest of the message in the thread.
|
|
Xapian may raise exceptions on some queries. Pass the error
along to the user so they can read Xapian documentation.
|
|
We'll be moving atom and thread display support inline
and reducing endpoints. Maybe it makes sense, maybe not.
|
|
Aallow navigating backwards and forwards, as some pages will be
bookmarked or some browsers may not have history. Also add a
link back to the index where they presumably came from.
While we're at it, limit the number of results we have to 25
for now to avoid making the page too big and wasting clients
memory for irrelevant results.
|
|
This hopefully makes it easier to find things without resorting
to proprietary external services.
|