i've noticed that some services out there seem to issue HEAD requests
to web sites as part of some sort of metadata fetching process about
links contained in content that they are processing (e.g. Mastodon).
currently we were just responding with 404's to these because actix
does not respond to HEAD requests for any route unless you explicitly
set up the request to respond that way (with the sole exception being
the default route handler in actix which is invoked for any type of
request)
they can still be used of course, but i feel like more people would
default to not using them, so i'd prefer the README to reflect this
by default. meh.
actix's `Logger` middleware would do this too for us, but it also
logs all requests in a "web access log" style which i find personally
extremely annoying and unhelpful
we don't really need anything pretty here since 99% of the time, the
error's that would be generated during a request will be something to
do with tera template rendering and thus, are probably only going to be
experienced while fiddling with the site. so we just want to display
the error details and move on.
the vast majority (if not all) of other errors will occuring during
startup and content reloading, and thus we only really need to worry
about them being logged to the console (which they are already)
actix will instead use http 308, which is technically the more correct,
modern way to do this.
but http 308 isn't understood by some old browsers. today, 99.9% of
people wouldn't care about that. but i do.
since we want html template modifications to trigger content refreshes,
we need to reload the Tera renderer because it internally is caching
loaded html templates.
to be used to turn sublime text themes to css files which can then
be included in a pbe site to apply appropriate styling to syntax
highlighted code blocks
i don't intend to support syntect's alternative inline css html
rendering functionality which would otherwise allow you to skip needing
a separate css file (at the cost of some html output that is a little
bit more bloated and less customizable from a web styling perspective)
while we are actually using a CommonMark renderer instead of Markdown,
i think i just prefer referring to everything related to this as
"markdown" for simplicity's sake. meh.
currently syntax highlighting is limited to the default syntax
definitions that syntect comes pre-loaded with (which is the same
as sublime text's out-of-the-box language support)
since most often, we need to get posts sorted in descending order by
date, we now just store the actual posts in a Vec, pre-sorted by date.
everything else that needs to reference posts now does so by the post's
index in that Vec.
pages are also changed to be stored/referenced in a similar manner, but
it is somewhat less important for pages since we don't do any real
enumeration of pages at all anywhere. but it's nice to be consistent.
posts can be specified with a date only, or date and time as desired.
it is up to the site's specific template to render posts with an
appropriate date/time format string based on what the author's
preferences
Gered