URL naming ---------- ### Unstable endpoints /$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/$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 [2] Do not make this into a 301 since feed readers may not follow them as well as normal browsers do. 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 . We also set to make window management easier. We favor <pre>-formatted text since public-inbox is intended as a place to share and discuss patches and code. Unfortunately, long paragraphs tends to be less readable with fixed-width serif fonts which GUI browsers default to. So perhaps we will add different endpoints for variable-width fonts. * 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 b) trust us and and run code without reading it * 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. w3m is fine here without CSS :) No other CSS is allowed, especially with scary things like: http://thejh.net/misc/website-terminal-copy-paste