5 /$INBOX/?r=$GIT_COMMIT -> HTML only
6 /$INBOX/new.atom -> Atom feed
8 #### Optional, relies on Search::Xapian
9 /$INBOX/$MESSAGE_ID/t/ -> HTML content of thread
11 #u location of $MESSAGE_ID in URL
12 #m<SHA-1> per-message links, where <SHA-1> is of the Message-ID
13 of each message (stable)
14 #s<NUM> relative numeric position of message in thread (unstable)
16 /$INBOX/$MESSAGE_ID/t.atom -> Atom feed for thread
17 /$INBOX/$MESSAGE_ID/t.mbox.gz -> gzipped mbox of thread
20 /$INBOX/$MESSAGE_ID/ -> HTML content
22 #r location of the current message in thread skeleton
23 (requires Xapian search)
24 #b start of the message body (linked from thread skeleton)
26 /$INBOX/$MESSAGE_ID -> 301 to /$INBOX/$MESSAGE_ID/
27 /$INBOX/$MESSAGE_ID/raw -> raw mbox
28 /$INBOX/$MESSAGE_ID/#R -> HTML reply instructions
30 # Covering up a pre-1.0 design mistake:
31 /$INBOX/$MESSAGE_ID/f/ -> 301 to /$INBOX/$MESSAGE_ID/
33 ### Legacy endpoints (may be ambiguous given Message-IDs with similar suffixes)
34 /$INBOX/m/$MESSAGE_ID/ -> 301 to /$INBOX/$MESSAGE_ID/
35 /$INBOX/m/$MESSAGE_ID.html -> 301 to /$INBOX/$MESSAGE_ID/
36 /$INBOX/m/$MESSAGE_ID.txt -> 301 to /$INBOX/$MESSAGE_ID/raw
37 /$INBOX/f/$MESSAGE_ID.html -> 301 to /$INBOX/$MESSAGE_ID/
38 /$INBOX/f/$MESSAGE_ID.txt [1] -> 301 to /$INBOX/$MESSAGE_ID/raw
40 /$INBOX/atom.xml [2] -> identical to /$INBOX/new.atom
42 Additionally, we support git clone/fetch over HTTP (dumb and smart):
44 git clone --mirror http://$HOSTNAME/$INBOX
46 FIXME: we must refactor/cleanup/add tests for most of our CGI before
47 adding more endpoints and features.
49 [1] These URLs were never linked, but only exist as a convenience to folks
50 who edit existing URLs
52 [2] Do not make this into a 301 since feed readers may not follow them as well
53 as normal browsers do.
58 Raw HTML and XML should only contain us-ascii characters which render
59 to UTF-8. We must not rely on users having the necessary fonts
60 installed to render uncommon characters.
62 Plain text (raw message) endpoints display in the original encoding(s)
63 of the original email.
65 Guidelines for using limited HTML
66 ---------------------------------
68 We mainly use HTML for linking pages together with <a>.
69 We also set <title> to make window management easier.
71 We favor <pre>-formatted text since public-inbox is intended as a place
72 to share and discuss patches and code. Unfortunately, long paragraphs
73 tends to be less readable with fixed-width serif fonts which GUI
76 * No graphics, images, or icons at all. We tolerate, but do not
77 encourage the use of GUIs.
79 * No setting colors or font sizes, power to users to decide those.
80 We will include and document <span class=?> to support colors
81 for user-supplied CSS.
83 * Only one font type: fixed. This is for accessibility, we must
84 not blow certain elements out-of-proportion with different
85 fonts on the page when a reader increases font size.
87 * Bold and underline elements are OK since they should render fine
88 regardless of chosen font and gracefully degrade if a display does
89 not support them. Italics and strike-through elements must be
90 avoided as they do not render well with some displays or user-chosen
93 * No JavaScript. JS is historically too buggy and insecure, and we will
94 never expect our readers to do either of the following:
95 a) read and audit all our code for on every single page load
96 b) trust us and and run code without reading it
98 * We only use CSS for one reason: wrapping pre-formatted text
99 This is necessary because unfortunate GUI browsers tend to be
100 prone to layout widening from unwrapped mailers.
101 w3m is fine here without CSS :)
102 No other CSS is allowed, especially with scary things like:
104 http://thejh.net/misc/website-terminal-copy-paste
106 However, we will try to make it easy for users to supply their
107 own colors via user-side CSS.
109 CSS classes (for user-supplied CSS)
110 -----------------------------------
111 span.q - quoted text in email messages