----------
### Unstable endpoints
-/$LISTNAME/?r=$GIT_COMMIT -> HTML only
-/$LISTNAME/atom.xml -> Atom feed
+/$LISTNAME/?r=$GIT_COMMIT -> HTML only
+/$LISTNAME/new.atom -> Atom feed
+
+#### Optional, relies on Search::Xapian
+/$LISTNAME/$MESSAGE_ID/t/ -> HTML content of thread
+/$LISTNAME/$MESSAGE_ID/t.atom -> Atom feed for thread
+/$LISTNAME/$MESSAGE_ID/t.mbox.gz -> gzipped mbox of thread
### Stable endpoints
-/$LISTNAME/m/$MESSAGE_ID.html -> HTML content (short quotes)
-/$LISTNAME/m/$MESSAGE_ID.txt -> raw original
-/$LISTNAME/m/$MESSAGE_ID -> 301 to .html version
-/$LISTNAME/f/$MESSAGE_ID.html -> HTML content (full quotes)
-/$LISTNAME/f/$MESSAGE_ID -> 301 to .html version
-/$LISTNAME/f/$MESSAGE_ID.txt -> 301 to m/$MESSAGE_ID.txt
+/$LISTNAME/$MESSAGE_ID/ -> HTML content (short quotes)
+/$LISTNAME/$MESSAGE_ID -> 301 to /$LISTNAME/$MESSAGE_ID
+/$LISTNAME/$MESSAGE_ID/raw -> raw mbox
+/$LISTNAME/$MESSAGE_ID/f/ -> HTML content (full quotes)
+/$LISTNAME/$MESSAGE_ID/R/ -> HTML reply instructions
+
+### Legacy endpoints (may be ambiguous given Message-IDs with similar suffixes)
+/$LISTNAME/m/$MESSAGE_ID/ -> 301 to /$LISTNAME/$MESSAGE_ID/
+/$LISTNAME/m/$MESSAGE_ID.html -> 301 to /$LISTNAME/$MESSAGE_ID/
+/$LISTNAME/m/$MESSAGE_ID.txt -> 301 to /$LISTNAME/$MESSAGE_ID/raw
+/$LISTNAME/f/$MESSAGE_ID.html -> 301 to /$LISTNAME/$MESSAGE_ID/f/
+/$LISTNAME/f/$MESSAGE_ID.txt [1] -> 301 to /$LISTNAME/$MESSAGE_ID/raw
+
+/$LISTNAME/atom.xml [2] -> identical to /$LISTNAME/new.atom
+
+Additionally, we support "git clone" pointed to http://$HOST/$LISTNAME
+
+FIXME: we must refactor/cleanup/add tests for most of our CGI before
+adding more endpoints and features.
+
+[1] These URLs were never linked, but only exist as a convenience to folks
+ who edit existing URLs
-Maybe TODO (these might be expensive)
--------------------------------------
-/$LISTNAME/t/$MESSAGE_ID.html -> HTML content of thread
-/$LISTNAME/t/$MESSAGE_ID.mbox -> mbox content of thread
+[2] Do not make this into a 301 since feed readers may not follow them as well
+ as normal browsers do.
-We use file name suffixes on all of these (except /) so URLs may easily
-cached/memoized using a static file server.
+Encoding notes
+--------------
+
+Raw HTML and XML should only contain us-ascii characters which render
+to UTF-8.
+
+Plain text (raw message) endpoints display in the original encoding(s)
+of the original email.
Guidelines for using limited HTML
---------------------------------
+
We mainly use HTML for linking pages together with <a>.
We also set <title> to make window management easier.
browsers default to. So perhaps we will add different endpoints for
variable-width fonts.
-* Do not build <a> links from user-generated-content, this prevents
- public-inbox deployments from being turned into a spam linkfarm.
-
* No graphics, images, or icons at all. We tolerate, but do not
encourage the use of GUIs.
* No setting colors or font sizes, power to users to decide those.
+* Only one font type (fixed or variable) per page. This is for
+ accessibility, we must not blow certain elements out-of-proportion
+ when a reader increases font size.
+
+* Bold and underline elements are OK since they should render fine
+ regardless of chosen font and gracefully degrade if a display does
+ not support them. Italics and strike-through elements must be
+ avoided as they do not render well with some displays or user-chosen
+ fonts.
+
* No JavaScript. JS is historically too buggy and insecure, and we will
never expect our readers to do either of the following:
a) read and audit all our code for on every single page load
* We only use CSS for one reason: wrapping pre-formatted text
This is necessary because unfortunate GUI browsers tend to be
- prone to layout widening. lynx is fine here without CSS :)
+ prone to layout widening. w3m is fine here without CSS :)
No other CSS is allowed, especially with scary things like:
http://thejh.net/misc/website-terminal-copy-paste