Date | Commit message (Collapse) |
|
Oops...
|
|
We only need XHTML-compatibility inside Atom feeds, as
anecdotally, feed readers are stricter than normal browsers and
some do not support HTML, only XHTML. So we will continue to
accomodate them. However we favor HTML elsewhere since it
tends to be smaller than the equivalent well-formed XHTML.
|
|
Oops :x
|
|
Another step towards a consistent WWW UI...
|
|
Automatic inbox switching was a potentially deceptive pattern
and surprises readers who do not check the URL bar closely.
Furthermore, a message could be cross-posted to multiple lists,
too.
|
|
This can be use to specify a small response using -html_tip.
|
|
They're uncommon, fortunately, but we make no attempt to
handle nested comments (which would open us up to things
like CVE-2015-7686) or use the comment in place of a
missing name.
|
|
Exposing compressed Message-IDs in URLs was a mistake,
remove a remnant of it.
|
|
If using a master/worker setup, a careless user could be trying
to signal all processes using "killall". This may trigger bad
side-effects; but try to limit the side-effects as much as
possible.
|
|
There is no point for diverting readers' attention with
an unnecessary link, here.
|
|
This will allow cache proxies such as Varnish to avoid
caching data sent by us.
|
|
git.git documentation uses "clonable" so that's probably
a better term than "clone-able". Also, shorten the section
for retrieving our code and remove an obvious typo.
|
|
This avoids breaking clients on graceful shutdown since
NNTP responses should usually be quick.
|
|
This ought to make things easier when we add TLS support.
|
|
This fills in the internal lookup hashes and simplifies
callers.
|
|
GoogleGroups URLs often contain '!' in them
|
|
Lighter and ever-so-slightly faster!
Most importantly, this won't do non-obvious stuff behind our
backs like trying to parse a POST request body for a query
string param.
|
|
Plack::Request will check the request body by merely
calling "param", totally unnecessary and sneaky.
|
|
More work on on the Plack::Request/CGI.pm removal front,
No need to access the PSGI env through an extra hash lookup.
|
|
This is less code and hopefully easier-to-understand.
|
|
This is lighter and we can work further towards eliminating
our Plack::Request dependency entirely.
|
|
Oops, fortunately this branch is only exposed to non-Xapian
users, right now.
|
|
It seems common for address entries to end up as:
"foo@example" <foo@example>
Avoid needlessly displaying the domain name in that case.
|
|
Note to self: remember to run tests
Fixes: 52052329aced ("git: allow cloning from the URL root, too")
|
|
This means we can still show non-git users a somewhat browseable
URL with a link to the README.html file while allowing git users
to type less when cloning.
All of the following are supported:
git clone https://public-inbox.org/ public-inbox
git clone https://public-inbox.org/public-inbox
git clone https://public-inbox.org/public-inbox.git
torsocks git clone http://ou63pmih66umazou.onion/public-inbox
|
|
Might as well eat our own dogfood...
|
|
No point in forcing users to pass a hashref/object to
get a single git directory.
|
|
Hrm... is there a more obvious way to do an internal API for
this while still being streamable?
|
|
We want to avoid the bare './' wherever possible, but it
doesn't seem possible here.
|
|
Oops :x I really need to whip check-inbox.perl into
shape or at least start running it, again.
Fixes: e29518088b3f ("view: fix up some HTML injection via Message-ID vectors")
|
|
This fixes the '^' (up) link in the $INBOX/new.html endpoint
for search-less displays.
|
|
I'm not sure what to show here, actually; but it's better
than triggering an uninitialized variable warning.
|
|
Storage is precious when it is forever and distributed.
And public-inbox aims to not only end Eternal September(*),
but to build a world less-centralized than Usenet ever was:
forkable discussion groups
(*) https://en.wikipedia.org/wiki/Eternal_September
|
|
This should make formatting more apparent since we can rely
on <pre> semantics.
|
|
This encapsulates an entire PSGI response array, hopefully
making it easier to generate responses and avoid typos when
setting the Content-Type.
|
|
Oops, this endpoint needs testing :x
|
|
* thread-view-skel:
view: show thread size when linking to summary
view: default to flat/hybrid thread display
view: fix up some HTML injection via Message-ID vectors
www: reinstate old thread view as an option
view: show more nearby messages in flat thread view
view: tweak thread/index header slightly
feed: add $INBOX/new.html endpoint
view: merge $state hash with existing $ctx
view: show thread context in the thread-aware flat view
www: use WwwStream for dumping thread and search views
www: implement hybrid flat+thread conversation view
|
|
This should give readers a better idea of what to expect.
|
|
This is friendlier for people on small screens and usually
eliminates the need to scroll horizontally.
|
|
Oops, these were only introduced during the hybrid flat thread
view reworking and never deployed.
|
|
This hybrid view is better than the old flat, but can
still fall down compared to the old threaded view in
some cases.
|
|
This reverts commit a391cf5aaf7181b5e5e20eb240c7ce50cbdf8fa2
as kernel.org is updating again. Ref:
http://mid.gmane.org/xmqqpor18a2n.fsf@gitster.mtv.corp.google.com
|
|
Context is important, but so is conserving precious screen
space. Decisions :<
|
|
This makes the top permalink/raw as well as the In-Reply-To
show up without search. While we're at it, try to make
the links on the thread index from the "X siblings, Y replies"
more obvious.
|
|
This acts like the Atom feed; but should be viewable directly
from browsers.
|
|
This reduces the level of indirection to reach certain objects
within the hash and there are no namespace or lifetime conflicts
anyways.
|
|
This lets user have a small window of the context of
the current message relative to other threads.
|
|
This allows us the HTTP server to react to backpressure
from slow clients when writing. As a side effect, this
also makes it easier for us to maintain a consistent
header/footer across our HTML.
|
|
This should be more accessible to readers on narrow terminals
(or giant fonts) while providing a chronological view which
is also aware of message threading relationships.
|
|
Oops, we cannot have bare '&' in mailto: links, either.
|