Upcoming Classes Should Be Listed TBD Until Set
Just an observation. When visiting the classroom page, it looks like there is nothing happening in the future. Of course from arch-general, we know that there is a Python for Beginners planned and that a poll is being taken for potential dates. When classes are planned, it would help if they were listed as upcoming (with date/time TBD) so that anyone stopping by the page isn't left with the impression there is nothing going on.
The description of Upcoming classes indicates that classes being developed should be listed, e.g.
The following table lists classes being developed and classes announced.
It's just a bit confusing to get notice on arch-general (with a link here), and then getting here and finding nothing.
David C. Rankin, J.D.,P.E. -- Rankin Law Firm, PLLC (talk) 18:41, 26 September 2017 (UTC)
Classroom logs show up garbled because Web server is not setting content-type charset correctly
The classroom logs are UTF-8 files, but the server they're on is sending them with a Content-Type of
text/plain with no
charset header. This results in browsers choosing the "ISO-8859-1" character set (as the HTTP spec requires; see below for more details on the spec) and rendering non-ASCII characters incorrectly. E.g., early in the logs of this package management class you'll see a line that should have been rendered as "eschwartz wanted you to have this cookie. 🍪" (the last character is the cookie emoji at Unicode codepoint U+1F36A). In UTF-8, that cookie emoji is represented by the four bytes
0xF0 0x9F 0x8D 0xAA. But because the server doesn't specify a Content-Type header of
text/plain; charset=utf-8, the browser *must* interpret those four bytes as ISO-8859-1, where they show up as "eschwartz wanted you to have this cookie. ðŸª". Which doesn't look nearly as friendly as what was intended. :-)
To fix this, someone with access to the Apache configuration for the archwomen.org site (where the logs are hosted) needs to change the default Content-Type header for .txt files to be
- Now for those "more details" about the HTTP spec. RFC 2616, the HTTP/1.1 spec, originally specified that the default for
text/plainfiles must be ISO-8859-1, but that RFC has been obsoleted by RFC 7231, which says "The default charset of ISO-8859-1 for text media types has beenremoved; the default is now whatever the media type definition says." The media type definition for
text/plainfiles can be found in RFC 6657, which says "The default "charset" parameter value for "text/plain" is unchanged from RFC 2046 and remains as "US-ASCII"." This is slightly inconsistent with what RFC 2616 requires (ISO-8859-1 vs US-ASCII), but since neither one is UTF-8, it hardly matters for the current purpose. Whether the browser interprets a UTF-8 file as US-ASCII or as ISO-8859-1, either way it will show an incorrect rendering of any characters outside the US-ASCII range (U+0000 through U+007F).