y.st./source/pages/en/weblog/2016/03-March/13.xhtml

<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Webkit isn&apos;t the problem',
	'body' => <<<END
<p>
	I checked in on the <a href="https://codereview.qt-project.org/#/c/152150/">Qt pull request</a> and found that it has been merged! If <a href="apt:arora">Arora</a> doesn&apos;t have it&apos;s own $a[SNI] bug, Arora is now fixed.
	Additionally, the <a href="https://bugzilla.gnome.org/show_bug.cgi?id=763510">$a[GNOME] bug report</a> has been changed again, this time to reflect that the bug is in glib and that it relates to networking in an unspecified version.
	People are actually looking at it and passing it to the developers of the particular subproject so that it can actually get fixed.
	This is better than I dared hope for! With a little luck, maybe the <a href="https://bugs.webkit.org/show_bug.cgi?id=155378">Webkit bug</a> will be taken seriously as well.
	However, while I was out, I saw that the Webkit people are saying that the &quot;host name/$a[SNI] mismatch&quot; error thrown by the server is caused by the fact that Webkit is sending the correct $a[HTTP] Host header and correct $a[SNI] host name, and because one has a trailing dot and the other does not, they don&apos;t match.
	As I&apos;ve tested what happens when you send the correct $a[SNI] host name and correct $a[HTTP] Host header, I knew that this isn&apos;t the case.
	I was under the impression that the &quot;mismatch&quot; was that the two didn&apos;t correspond with one another because the trailing dot $a[SNI] host name doesn&apos;t correspond with <strong>*any*</strong> $a[HTTP] Host header, as it&apos;s invalid.
	I thought that I&apos;d have to set up my own $a[HTTP] server that the Webkit people could access, which would be a breach of my $a[ISP]&apos;s terms of service.
	With my own Web server, I might be able to nudge my server into providing access to my Web application by using a couple lines of code in a $a[PHP]-based 400 error page.
	After running into a strange error in Iceweasel that prevented me from loading the $a[SNI] testing page (Iceweasel refused to allow me to accept the &quot;invalid&quot; certificate), I tried a subdomain of the main testing page because the certificate specifically mentioned being valid for two subdomains.
	Much to my surprise, I found that not only did the new page not set off Iceweasel&apos;s anti-$a[TLS] error, it also didn&apos;t set of the server&apos;s error, despite the fact that the Web browser was still sending a malformed $a[SNI] host name.
	Using this to my advantage, I was able to show the show the Webkit people the malformed $a[SNI] host name sant by Web browsers using their software.
	By the end of the night, they did understand the problem.
	However, they say that the bug isn&apos;t in Webkit, but somewhere else.
	The person I spoke with confirmed that the error is in Safari (which I couldn&apos;t test myself), Chrome (Which I assumed had the error because <a href="apt:chromium">Chromium</a> does), and <a href="apt:iceweasel">Firefox</a> (which I already reported the bug in).
	He said he&apos;d pass the information on to Apple so that they can fix Safari, which should lead to one more Web browser being fixed.
	However, it means that I still need to figure out who to report the problem in <a href="apt:surf">Surf</a> to.
</p>
<p>
	Speaking of playing games with the 400 error page, I found that I can display an actual page on my choosing in place of the default 400 error page, though doing so is less intuitive than I&apos;d like.
	It might be possible to write a tricky 400 error page that checks to see if the cause of the error is a malformed $a[SNI] host name, and if it is, return the page that would have otherwise been returned if the $a[SNI] host name wans&apos;t present or was correct.
	I might use this for a Web-based game if I have time to build it.
	People that are running reasonable Web browsers might get a bonus while those running unreasonable Web browsers might get an inverse bonus and be presented with a link to an explanation.
	The explanation would provide links to the bug reports on known Web browsers and invite the user to either pressure the developers into fixing them, file their own bug report against an unlisted Web browser, or switch to a known-working Web browser.
</p>
<p>
	I spent most of the day in Springfield, trying to remove a broken faucet to replace it with one that might work.
	However, most likely due to heavy corrosion, I wans&apos;t able to fully remove it.
	I&apos;m not sure what we&apos;re going to have to do about it.
</p>
<p>
	On the way home, I was thinking about moss and wondering if it&apos;s harmful to the trees it grows on.
	I thought that I recalled hearing that moss doesn&apos;t sap the nutrients out of trees, but the roots of the moss digging into the tree had to be doing damage.
	And if the moss is digging into the tree, why doesn&apos;t the tree&apos;s immune system fight off the moss? I looked it up on the way back, and it turns out that <a href="http://1800cuttree.com/content/moss-bad-trees">moss isn&apos;t in fact harmful to most trees</a> and isn&apos;t a parasite.
	While moss does produce threadlike structures that help it hold onto the tree, it has no roots and doesn&apos;t actually dig into the tree.
	This probably explains why moss can grow so well on stones too.
	The biggest threat that moss poses to trees seems to be its weight.
	If a particularly weakened and/or old tree has too much damp moss on it, it might not be able to support it all and that could lead to breaking.
</p>
END
);