{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mstdn.party/@albert_inkman/116371848929933495",
    "content": {
        "html": "<p>RSS was the last protocol that let you follow anything without giving a company your attention graph. We killed it because it couldn't be monetized.</p><p>The fediverse is the second attempt at open syndication. This time the architecture knows what happened to the first one.</p><p><a href=\"https://mstdn.party/tags/fediverse\">#<span>fediverse</span></a> <a href=\"https://mstdn.party/tags/ActivityPub\">#<span>ActivityPub</span></a> <a href=\"https://mstdn.party/tags/OpenSource\">#<span>OpenSource</span></a> <a href=\"https://mstdn.party/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "RSS was the last protocol that let you follow anything without giving a company your attention graph. We killed it because it couldn't be monetized.\n\nThe fediverse is the second attempt at open syndication. This time the architecture knows what happened to the first one.\n\n#fediverse #ActivityPub #OpenSource #IndieWeb"
    },
    "published": "2026-04-09T00:11:36+00:00",
    "post-type": "note",
    "_id": "47891541",
    "_source": "8007",
    "_is_read": true
}

Code: Specification vs. implementation

{
    "type": "entry",
    "author": {
        "name": "fluffy",
        "url": "http://beesbuzz.biz/",
        "photo": null
    },
    "url": "http://beesbuzz.biz/code/6604-Specification-vs.-implementation",
    "published": "2026-04-08T14:04:57-07:00",
    "content": {
        "html": "<p>There are a lot of times when the specification says one thing but common implementations do another. Here are some especially common examples to watch out for.</p>\n\n\n<h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_1_Attribute-quoting\"></a>Attribute quoting</h3><p>According to <a href=\"https://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.2\">the HTML specification</a>, single-quoted attributes are perfectly valid; for example, these HTML fragments should be absolutely equivalent:</p><pre><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb1L1\"></a>&lt;a href=\"https://example.com/\"&gt;Check out my website&lt;/a&gt;\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb1L2\"></a>&lt;a href='https://example.com/'&gt;Check out my website&lt;/a&gt;\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb1L3\"></a>&lt;a href=https://example.com/&gt;Check out my website&lt;/a&gt;\n</pre><p>However, there are <em>many, many</em> client implementations which expect any quoted attributes to be double-quoted, and even some which do not support unquoted attributes at all. So, for example, I\u2019ve seen many implementations assume that a single-quoted attribute is equivalent to an unquoted attribute, so it treats <em>these</em> as equivalent:</p><pre><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb2L1\"></a>&lt;a href='https://example.com/'&gt;Check out my website&lt;/a&gt;\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb2L2\"></a>&lt;a href=\"'https://example.com/'\"&gt;Check out my website&lt;/a&gt;\n</pre><p>which is to say, if <code>&lt;a href='https://example.com/'&gt;Check out my website&lt;/a&gt;</code> appears on the website <code>https://foo.example/~bob/homepage.html</code>, the URL then is interpreted as being <code>https://foo.example/~bob/'https://example.com'</code> (or <code>https://foo.example/~bob/%39https://example.com%39</code> if we\u2019re being strict about URL-encoding).</p><p>Unquoted attributes also often are subject to all sorts of weird things, especially with how the entities within them get decoded.</p><p>Email systems are historically <em>particularly</em> bad about this; the impetus to this article was discovering that my email provider<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#d_e6604_fn1\">1</a> does not support single-quoted attributes, and goes so far as to converting the quotes to <code>&amp;#39;</code> entities, causing even more problems downstream.</p><p>So, for maximum compatibility, it\u2019s best to always use double-quoted attributes, regardless of what the HTML specification says.</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_2_Protocol-relative-URLs\"></a>Protocol-relative URLs</h3><p>Back in the day, it was pretty common for websites to serve things up in a mixture of HTTP (plaintext) and HTTPS (encrypted), and there were reasons to want static pages to link to external resources with the same scheme (for example, an HTTP page referring to an external image with an HTTP URL, but the HTTPS version of the page using an HTTPS URL for the image).</p><p>I cannot find any official specification for HTML, but the commonly-accepted standard for these, per the <a href=\"https://www.w3.org/Addressing/URL/5_URI_BNF.html\">generic URI syntax</a>, considers the initial <code>//hostname</code> to be the starting portion of the path component of the URL, which is to say, a protocol-relative URL of <code>//example.com/foo</code> should be treated by adding the current page\u2019s scheme to the URL; for example, from <code>https://example.com/~bob/homepage.html</code>, a link to <code>//website.example/meow.gif</code> should be interpreted as <code>https://website.example/meow.gif</code>, while from <code>http://example.com/~alice/</code> the same link would become <code>http://website.example/meow.gif</code>.</p><p>Unfortunately, a <em>lot</em> of software out there just sees that the link starts with a <code>/</code> and assumes it\u2019s a site-relative URL instead, so from <code>https://example.com/~bob/</code> it is interpreted as <code>https://example.com/website.example/meow.gif</code>.</p><p>You can see how your browser implements <a href=\"http://sockpuppet.band/track/the-war-machine\">such a link</a>.</p><p>In any case, it\u2019s better to be explicit about your URL scheme, and in general if a site supports <code>https</code> it\u2019s best to just link to that version anyway.</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_3_Path-coalescing\"></a>Path coalescing</h3><p>In most operating systems, there is a convention that <code>..</code> refers to the parent directory, so for example the path <code>/foo/bar/../baz</code> is equivalent to <code>/foo/baz</code>. Additionally, <code>.</code> refers to the current directory, and <code>/</code> is seen as a path separator. So a path of <code>/foo/bar/./baz</code> is equivalent to <code>/foo/bar/baz</code>, for example.</p><p>Most web-based things will automatically apply these rules, even if it\u2019s technically incorrect; for example, both Apache and nginx will internally manipulate the URL to treat them as equivalent before it even touches the backing application, and even if they don\u2019t, it seems that most application stacks will also pre-coalesce the URL.</p><p>But on the client side, browsers will also automatically do this path coalescing before it even forms the URL to be requested; for example, <a href=\"http://beesbuzz.biz/blog/\"><code>../blog/</code></a> and even <a href=\"https://junk.sockpuppet.band/foo/bar/../../songlets/\"><code>https://junk.sockpuppet.band/foo/bar/../../songlets/</code></a> never even show up in the DOM with any of the <code>..</code> components from most browsers (although I have seen some clients preserve them in some cases). Strictly-speaking those URLs shouldn\u2019t even be equivalent, because <code>foo/bar</code> is a nonexistent path on both of those sites, so based purely on filesystem rules those <em>should</em> result in a <a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/404\">404 Not Found</a> error. But things are being short-circuited for the sake of friendliness. And if you enter a URL manually, by copy-pasting e.g. <code>https://beesbuzz.biz/foo/../code/</code> into your location bar, every modern browser I\u2019ve tried will just automagically coalesce the path component.</p><p>(Note that how it coalesces <code>//</code> is inconsistent, in my experience; some browsers treat it as a subdirectory with an empty name, while others treat it as if it\u2019s the same as a single <code>/</code>, the same as UNIX.)</p><p>But it\u2019s not necessarily the case that the path <em>will</em> be coalesced. For example, here\u2019s a trivial <a href=\"https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface\">WSGI</a> application that just passes through a couple of things from the request:</p>app.py<pre><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb3L1\"></a>def app(environ, start_response):\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb3L2\"></a>    start_response(\"200 OK\", [(\"Content-Type\", \"text/plain\")])\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb3L3\"></a>\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb3L4\"></a>    for key in ('HTTP_HOST', 'RAW_URI'):\n<a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#e6604cb3L5\"></a>        yield f'{key}: {environ[key]}\\n'.encode('utf-8')\n</pre><p>And here\u2019s some outputs when run through <a href=\"https://gunicorn.org/\">gunicorn</a>; for starters, by default, curl coalesces <code>/./</code> and <code>/../</code> (but not <code>//</code>) client-side:</p><pre>bean:~ $ curl -i http://localhost:8000/foo//moo/./bar/../baz/\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:36:44 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo//moo/baz/\nbean:~ $ curl -i http://localhost:8000/foo//moo/../../bar/\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:42:56 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo/bar/\n</pre><p>But a request that uses the path as-is will still at least pass through directly, at least through gunicorn itself:</p><pre>bean:~ $ curl -i http://localhost:8000/foo//moo/./bar/../baz/ --path-as-is\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:40:09 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo//moo/./bar/../baz/\n</pre><p>But in other testing I have found that, at least with a stack of nginx+gunicorn+Flask, the path coalescing takes place <em>somewhere</em> before it hits the actual application. (I do not have the patience to try to figure out where, exactly, not that it even matters.)</p><p>All this is to say, you <em>cannot</em> expect runs of multiple <code>/</code> or paths containing <code>/./</code> or <code>/../</code> to remain intact, even when the request is being made at the wire level, but you also cannot assume that the path <em>will</em> be pre-coalesced.</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_4_Case-sensitivity-case-folding\"></a>Case-sensitivity/case-folding</h3><p>Case-sensitivity and lack thereof in the hostname is also something you cannot rely on:</p><pre>$ curl -ivvv http://beesbuzz.biz/ | head\n* Host beesbuzz.biz:80 was resolved.\n[...]\n&gt; GET / HTTP/1.1\n&gt; Host: beesbuzz.biz\n[...]\n&lt; link: &lt;https://webmention.io/beesbuzz.biz/webmention&gt;; rel=\"webmention\"\n&lt; Link: &lt;https://beesbuzz.biz/_tokens&gt;; rel=\"token_endpoint\"\n[...]\n\n$ curl -sivvv http://BeesBuzz.Biz/ | head\n* Host BeesBuzz.Biz:80 was resolved.\n[...]\n&gt; GET / HTTP/1.1\n&gt; Host: BeesBuzz.Biz\n[...]\n&lt; link: &lt;https://webmention.io/beesbuzz.biz/webmention&gt;; rel=\"webmention\"\n&lt; Link: &lt;https://beesbuzz.biz/_tokens&gt;; rel=\"token_endpoint\"\n[...]\n</pre><p>In this case, note that <code>curl</code> preserved the case of the domain name in the <code>Host:</code> parameter, but something within the stack converted the hostname to all-lowercase (as can be seen in the <code>link</code> headers in the response). Whether this is happening in nginx or Flask is uncertain (and I, again, do not feel a particular need to figure out where this takes place, although I\u2019d assume it\u2019s at the vhost \u2014 and therefore nginx \u2014 level), but gunicorn does preserve the case of the hostname (using the same minimal WSGI app as above):</p><pre>bean:~ $ curl http://LocalHost:8000/\nHTTP_HOST: LocalHost:8000\nRAW_URI: /\n</pre><p>So, as with path coalescing, you cannot assume that elements will be case-folded for you, but you also cannot assume that they <em>won\u2019t</em> be.</p><p>And of course, path resolution for resources is up to the underlying implementation; a webserver running on macOS or Windows will (usually) treat <code>/foo.jpg</code> and <code>/foo.JPG</code> as the same resource, while on Linux, those are different resources. Of course the browser will <em>hopefully</em> treat them as separate for the purpose of caching, but: <strong><em>you cannot guarantee this</em></strong>.</p><p>As one of my college professors once said, \u201cIf it makes a difference whether something is case-sensitive or not, you have made a mistake.\u201d</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_5_http-vs.-https-in-general\"></a>http vs. https in general</h3><p>Nothing in the HTTP specification says that the same path on two different schemes will reflect the same resource; for example, <code>http://example.com/</code> and <code>https://example.com/</code> can very well be completely different websites. But I have seen plenty of browsers, web crawlers, and other software assume that they are the one and the same!</p><p>At its most trivial, this very site will have slightly different content for the two versions; there are a handful of places where out of necessity, some links do not appear on the <code>http</code> version, or where they are rendered as absolute links and will match the original request\u2019s scheme rather than directing to <code>https</code>.</p><p>But things can be a lot more complicated. For example, once upon a time I ran a site where the <code>http</code> version was an informational page and the <code>https</code> version was the webmail for the domain. It was silly to do it that way, and I stopped doing it when browsers started being \u201chelpful\u201d about automatically converting http URLs to https (not to mention when I stopped hosting my own email and switched to other hosting providers), but you absolutely cannot just assume that two pages will be the same despite different URL schemes.</p><p>(Also, remember that URL schemes other than <code>http</code> and <code>https</code> exist! FTP, Gopher, and others might have fallen out of fashion, but they still exist. Not to mention nascent protocols like <a href=\"https://geminiprotocol.net/\">Gemini</a>.)</p><p>From a server implementation standpoint, you should assume that clients can and will treat differing schemes as identical, so if a website is available from both protocols, the content should match between them, and if something is only available via <code>https</code>, then an <code>http</code> request to the same resource should redirect to the <code>https</code> one.</p><p>But from a client standpoint, you really should consider the scheme to be a part of the URL.</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_6_www.-prefixes-and-other-subdomai\"></a><code>www.</code> prefixes (and other subdomain issues)</h3><p>Back in the early days of the Internet, it was common for a domain to host a whole bunch of different services, for example <code>ftp.example.com</code>, <code>irc.example.com</code>, <code>mail.example.com</code>, and so on, and many of these would even be hosted by separate physical servers with their own IP addresses. So when the web started up as an experimental thing it was super common to just spin up another server named <code>www</code>, and that was the one and only way that people would reference the website; there often wouldn\u2019t even <em>be</em> a root domain <code>A</code> record.</p><p>In those days, the hostname used to resolve the site had no impact on the resource returned; in fact the <code>Host:</code> request header didn\u2019t even exist, and it wasn\u2019t until quite some time later that browsers started sending that, to support <a href=\"https://en.wikipedia.org/wiki/Virtual_hosting\">name-based virtual hosting</a>. Every website needed its own IP address. (Note that many non-HTTP protocols still have this limitation.)</p><p>As the web became the primary use of the Internet, the <code>www</code> prefix convention remained, and you had a big hot mess of differing implementations:</p>\n<ul><li>Dedicated-IP hosts that have the root record <em>and</em> <code>www</code> resolve to the same server, which would then serve up the same content on either hostname</li>\n<li>Sites that would map both <code>example.com</code> and <code>www.example.com</code> to the same virtual host configuration</li>\n<li>Sites that would redirect <code>www.example.com</code> to <code>example.com</code></li>\n<li>Sites that would redirect <code>example.com</code> to <code>www.example.com</code></li>\n<li>Sites that serve up entirely different content for <code>example.com</code> vs. <code>www.example.com</code></li>\n<li>Hosts that only resolve from one or the other</li>\n</ul><p>Pretty much all of these remain to this very day, and to make things even more fun, many clients try to do \u201chelpful\u201d things where, for example, if <code>example.com</code> doesn\u2019t resolve it\u2019ll automatically redirect to <code>www.example.com</code> (or put up a prompt to that effect), or if a web crawler sees both hostnames it\u2019ll just assume that both are the same, or follow the preference of whomever implemented it.</p><p>I don\u2019t even know what the best practice should be in this case. I guess it should be something like:</p>\n<ul><li>Clients should assume that <code>www.example.com</code> and <code>example.com</code> are different websites and use <a href=\"https://www.rfc-editor.org/rfc/rfc6596\">canonical URLs</a> to sort out which is the \u201creal\u201d one if they both exist, even if this means potentially crawling the same site twice</li>\n<li>Servers should redirect to the one that is correct</li>\n</ul><p>Then again, the same issue comes up with sites that are available from multiple separate domains, and I\u2019ve also seen situations where badly-behaved crawlers will assume that <em>all</em> subdomains are equivalent (e.g. <code>alice.example.com</code> and <code>bob.example.com</code>), sometimes even getting confused by ccTLDs that are multi-level (like <code>.uk</code>) and thinking that, for example, <code>example.co.uk</code> and <code>google.co.uk</code> are the same site because they\u2019re both subdomains of <code>co.uk</code>! (This was especially bad back when so-called \u201cdynamic DNS\u201d providers were super common.)</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_7_Redirections\"></a>Redirections</h3><p>There are <a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections\">so many different kinds of HTTP redirection</a>, each with different implications on caching, HTTP method, and equivalence.</p><p>Clients should probably just note the type and target of a redirection rather than try to treat the URLs as equivalent; for example, <a href=\"http://beesbuzz.biz/code\"><code>/code</code></a> and <a href=\"http://beesbuzz.biz/code/\"><code>/code/</code></a> are distinct URLs and should be treated as such.</p><p>Like, in theory, <code>/code</code> could <em>not</em> redirect and instead have entirely different content from <code>/code/</code>, but in practice, this will almost certainly cause Problems, and I\u2019m sure there\u2019s even crawlers out there which strip off trailing slashes and then expect the actual request to be redirected.</p><h3><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#6604_h3_8_In-conclusion\"></a>In conclusion</h3><p>When implementing client software, you should do whatever you can to follow the specification, but when implementing server software, you should also be aware of common client implementation issues.</p><p>If you do run into an implementation issue, it is of course a kindness to inform the implementor of the mistake, but some of these issues are common enough that it\u2019s best to accommodate the common misunderstandings and just sigh quietly about it.</p>\n\n<ol><li><p>I have of course reported this as a bug. They are, incidentally, otherwise amazing; use <a href=\"https://join.fastmail.com/673cc1b3\">my referral link</a> for 10% off your first year of service. <a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#r_e6604_fn1\">\u21a9</a></p></li></ol><p><a href=\"http://beesbuzz.biz/code/6604-Specification-vs.-implementation#comments\">comments</a></p>\n\n        \n        <a href=\"http://beesbuzz.biz/code/?id=6604&amp;tag=html\">#HTML</a>\n        \n        <a href=\"http://beesbuzz.biz/code/?id=6604&amp;tag=conformance\">#conformance</a>",
        "text": "There are a lot of times when the specification says one thing but common implementations do another. Here are some especially common examples to watch out for.\n\n\nAttribute quotingAccording to the HTML specification, single-quoted attributes are perfectly valid; for example, these HTML fragments should be absolutely equivalent:<a href=\"https://example.com/\">Check out my website</a>\n<a href='https://example.com/'>Check out my website</a>\n<a href=https://example.com/>Check out my website</a>\nHowever, there are many, many client implementations which expect any quoted attributes to be double-quoted, and even some which do not support unquoted attributes at all. So, for example, I\u2019ve seen many implementations assume that a single-quoted attribute is equivalent to an unquoted attribute, so it treats these as equivalent:<a href='https://example.com/'>Check out my website</a>\n<a href=\"'https://example.com/'\">Check out my website</a>\nwhich is to say, if <a href='https://example.com/'>Check out my website</a> appears on the website https://foo.example/~bob/homepage.html, the URL then is interpreted as being https://foo.example/~bob/'https://example.com' (or https://foo.example/~bob/%39https://example.com%39 if we\u2019re being strict about URL-encoding).\n\nUnquoted attributes also often are subject to all sorts of weird things, especially with how the entities within them get decoded.\n\nEmail systems are historically particularly bad about this; the impetus to this article was discovering that my email provider1 does not support single-quoted attributes, and goes so far as to converting the quotes to &#39; entities, causing even more problems downstream.\n\nSo, for maximum compatibility, it\u2019s best to always use double-quoted attributes, regardless of what the HTML specification says.Protocol-relative URLsBack in the day, it was pretty common for websites to serve things up in a mixture of HTTP (plaintext) and HTTPS (encrypted), and there were reasons to want static pages to link to external resources with the same scheme (for example, an HTTP page referring to an external image with an HTTP URL, but the HTTPS version of the page using an HTTPS URL for the image).\n\nI cannot find any official specification for HTML, but the commonly-accepted standard for these, per the generic URI syntax, considers the initial //hostname to be the starting portion of the path component of the URL, which is to say, a protocol-relative URL of //example.com/foo should be treated by adding the current page\u2019s scheme to the URL; for example, from https://example.com/~bob/homepage.html, a link to //website.example/meow.gif should be interpreted as https://website.example/meow.gif, while from http://example.com/~alice/ the same link would become http://website.example/meow.gif.\n\nUnfortunately, a lot of software out there just sees that the link starts with a / and assumes it\u2019s a site-relative URL instead, so from https://example.com/~bob/ it is interpreted as https://example.com/website.example/meow.gif.\n\nYou can see how your browser implements such a link.\n\nIn any case, it\u2019s better to be explicit about your URL scheme, and in general if a site supports https it\u2019s best to just link to that version anyway.Path coalescingIn most operating systems, there is a convention that .. refers to the parent directory, so for example the path /foo/bar/../baz is equivalent to /foo/baz. Additionally, . refers to the current directory, and / is seen as a path separator. So a path of /foo/bar/./baz is equivalent to /foo/bar/baz, for example.\n\nMost web-based things will automatically apply these rules, even if it\u2019s technically incorrect; for example, both Apache and nginx will internally manipulate the URL to treat them as equivalent before it even touches the backing application, and even if they don\u2019t, it seems that most application stacks will also pre-coalesce the URL.\n\nBut on the client side, browsers will also automatically do this path coalescing before it even forms the URL to be requested; for example, ../blog/ and even https://junk.sockpuppet.band/foo/bar/../../songlets/ never even show up in the DOM with any of the .. components from most browsers (although I have seen some clients preserve them in some cases). Strictly-speaking those URLs shouldn\u2019t even be equivalent, because foo/bar is a nonexistent path on both of those sites, so based purely on filesystem rules those should result in a 404 Not Found error. But things are being short-circuited for the sake of friendliness. And if you enter a URL manually, by copy-pasting e.g. https://beesbuzz.biz/foo/../code/ into your location bar, every modern browser I\u2019ve tried will just automagically coalesce the path component.\n\n(Note that how it coalesces // is inconsistent, in my experience; some browsers treat it as a subdirectory with an empty name, while others treat it as if it\u2019s the same as a single /, the same as UNIX.)\n\nBut it\u2019s not necessarily the case that the path will be coalesced. For example, here\u2019s a trivial WSGI application that just passes through a couple of things from the request:app.pydef app(environ, start_response):\n    start_response(\"200 OK\", [(\"Content-Type\", \"text/plain\")])\n\n    for key in ('HTTP_HOST', 'RAW_URI'):\n        yield f'{key}: {environ[key]}\\n'.encode('utf-8')\nAnd here\u2019s some outputs when run through gunicorn; for starters, by default, curl coalesces /./ and /../ (but not //) client-side:bean:~ $ curl -i http://localhost:8000/foo//moo/./bar/../baz/\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:36:44 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo//moo/baz/\nbean:~ $ curl -i http://localhost:8000/foo//moo/../../bar/\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:42:56 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo/bar/\nBut a request that uses the path as-is will still at least pass through directly, at least through gunicorn itself:bean:~ $ curl -i http://localhost:8000/foo//moo/./bar/../baz/ --path-as-is\nHTTP/1.1 200 OK\nServer: gunicorn\nDate: Wed, 08 Apr 2026 20:40:09 GMT\nConnection: close\nTransfer-Encoding: chunked\nContent-Type: text/plain\n\nHTTP_HOST: localhost:8000\nRAW_URI: /foo//moo/./bar/../baz/\nBut in other testing I have found that, at least with a stack of nginx+gunicorn+Flask, the path coalescing takes place somewhere before it hits the actual application. (I do not have the patience to try to figure out where, exactly, not that it even matters.)\n\nAll this is to say, you cannot expect runs of multiple / or paths containing /./ or /../ to remain intact, even when the request is being made at the wire level, but you also cannot assume that the path will be pre-coalesced.Case-sensitivity/case-foldingCase-sensitivity and lack thereof in the hostname is also something you cannot rely on:$ curl -ivvv http://beesbuzz.biz/ | head\n* Host beesbuzz.biz:80 was resolved.\n[...]\n> GET / HTTP/1.1\n> Host: beesbuzz.biz\n[...]\n< link: <https://webmention.io/beesbuzz.biz/webmention>; rel=\"webmention\"\n< Link: <https://beesbuzz.biz/_tokens>; rel=\"token_endpoint\"\n[...]\n\n$ curl -sivvv http://BeesBuzz.Biz/ | head\n* Host BeesBuzz.Biz:80 was resolved.\n[...]\n> GET / HTTP/1.1\n> Host: BeesBuzz.Biz\n[...]\n< link: <https://webmention.io/beesbuzz.biz/webmention>; rel=\"webmention\"\n< Link: <https://beesbuzz.biz/_tokens>; rel=\"token_endpoint\"\n[...]\nIn this case, note that curl preserved the case of the domain name in the Host: parameter, but something within the stack converted the hostname to all-lowercase (as can be seen in the link headers in the response). Whether this is happening in nginx or Flask is uncertain (and I, again, do not feel a particular need to figure out where this takes place, although I\u2019d assume it\u2019s at the vhost \u2014 and therefore nginx \u2014 level), but gunicorn does preserve the case of the hostname (using the same minimal WSGI app as above):bean:~ $ curl http://LocalHost:8000/\nHTTP_HOST: LocalHost:8000\nRAW_URI: /\nSo, as with path coalescing, you cannot assume that elements will be case-folded for you, but you also cannot assume that they won\u2019t be.\n\nAnd of course, path resolution for resources is up to the underlying implementation; a webserver running on macOS or Windows will (usually) treat /foo.jpg and /foo.JPG as the same resource, while on Linux, those are different resources. Of course the browser will hopefully treat them as separate for the purpose of caching, but: you cannot guarantee this.\n\nAs one of my college professors once said, \u201cIf it makes a difference whether something is case-sensitive or not, you have made a mistake.\u201dhttp vs. https in generalNothing in the HTTP specification says that the same path on two different schemes will reflect the same resource; for example, http://example.com/ and https://example.com/ can very well be completely different websites. But I have seen plenty of browsers, web crawlers, and other software assume that they are the one and the same!\n\nAt its most trivial, this very site will have slightly different content for the two versions; there are a handful of places where out of necessity, some links do not appear on the http version, or where they are rendered as absolute links and will match the original request\u2019s scheme rather than directing to https.\n\nBut things can be a lot more complicated. For example, once upon a time I ran a site where the http version was an informational page and the https version was the webmail for the domain. It was silly to do it that way, and I stopped doing it when browsers started being \u201chelpful\u201d about automatically converting http URLs to https (not to mention when I stopped hosting my own email and switched to other hosting providers), but you absolutely cannot just assume that two pages will be the same despite different URL schemes.\n\n(Also, remember that URL schemes other than http and https exist! FTP, Gopher, and others might have fallen out of fashion, but they still exist. Not to mention nascent protocols like Gemini.)\n\nFrom a server implementation standpoint, you should assume that clients can and will treat differing schemes as identical, so if a website is available from both protocols, the content should match between them, and if something is only available via https, then an http request to the same resource should redirect to the https one.\n\nBut from a client standpoint, you really should consider the scheme to be a part of the URL.www. prefixes (and other subdomain issues)Back in the early days of the Internet, it was common for a domain to host a whole bunch of different services, for example ftp.example.com, irc.example.com, mail.example.com, and so on, and many of these would even be hosted by separate physical servers with their own IP addresses. So when the web started up as an experimental thing it was super common to just spin up another server named www, and that was the one and only way that people would reference the website; there often wouldn\u2019t even be a root domain A record.\n\nIn those days, the hostname used to resolve the site had no impact on the resource returned; in fact the Host: request header didn\u2019t even exist, and it wasn\u2019t until quite some time later that browsers started sending that, to support name-based virtual hosting. Every website needed its own IP address. (Note that many non-HTTP protocols still have this limitation.)\n\nAs the web became the primary use of the Internet, the www prefix convention remained, and you had a big hot mess of differing implementations:\nDedicated-IP hosts that have the root record and www resolve to the same server, which would then serve up the same content on either hostname\nSites that would map both example.com and www.example.com to the same virtual host configuration\nSites that would redirect www.example.com to example.com\nSites that would redirect example.com to www.example.com\nSites that serve up entirely different content for example.com vs. www.example.com\nHosts that only resolve from one or the other\nPretty much all of these remain to this very day, and to make things even more fun, many clients try to do \u201chelpful\u201d things where, for example, if example.com doesn\u2019t resolve it\u2019ll automatically redirect to www.example.com (or put up a prompt to that effect), or if a web crawler sees both hostnames it\u2019ll just assume that both are the same, or follow the preference of whomever implemented it.\n\nI don\u2019t even know what the best practice should be in this case. I guess it should be something like:\nClients should assume that www.example.com and example.com are different websites and use canonical URLs to sort out which is the \u201creal\u201d one if they both exist, even if this means potentially crawling the same site twice\nServers should redirect to the one that is correct\nThen again, the same issue comes up with sites that are available from multiple separate domains, and I\u2019ve also seen situations where badly-behaved crawlers will assume that all subdomains are equivalent (e.g. alice.example.com and bob.example.com), sometimes even getting confused by ccTLDs that are multi-level (like .uk) and thinking that, for example, example.co.uk and google.co.uk are the same site because they\u2019re both subdomains of co.uk! (This was especially bad back when so-called \u201cdynamic DNS\u201d providers were super common.)RedirectionsThere are so many different kinds of HTTP redirection, each with different implications on caching, HTTP method, and equivalence.\n\nClients should probably just note the type and target of a redirection rather than try to treat the URLs as equivalent; for example, /code and /code/ are distinct URLs and should be treated as such.\n\nLike, in theory, /code could not redirect and instead have entirely different content from /code/, but in practice, this will almost certainly cause Problems, and I\u2019m sure there\u2019s even crawlers out there which strip off trailing slashes and then expect the actual request to be redirected.In conclusionWhen implementing client software, you should do whatever you can to follow the specification, but when implementing server software, you should also be aware of common client implementation issues.\n\nIf you do run into an implementation issue, it is of course a kindness to inform the implementor of the mistake, but some of these issues are common enough that it\u2019s best to accommodate the common misunderstandings and just sigh quietly about it.\n\nI have of course reported this as a bug. They are, incidentally, otherwise amazing; use my referral link for 10% off your first year of service. \u21a9comments\n\n        \n        #HTML\n        \n        #conformance"
    },
    "name": "Code: Specification vs. implementation",
    "post-type": "article",
    "_id": "47891504",
    "_source": "3782",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mstdn.party/@albert_inkman/116372202003272669",
    "content": {
        "html": "<p>Amazon bricking pre-2013 Kindles in May. Your 'library' requires their permission to exist.</p><p>This is the endgame of every 'you license it, you don't own it' model. The books you bought will outlive the device but not the DRM.</p><p>Physical shelves don't need servers.</p><p><a href=\"https://mstdn.party/tags/OpenSource\">#<span>OpenSource</span></a> <a href=\"https://mstdn.party/tags/IndieWeb\">#<span>IndieWeb</span></a> <a href=\"https://mstdn.party/tags/fediverse\">#<span>fediverse</span></a></p>",
        "text": "Amazon bricking pre-2013 Kindles in May. Your 'library' requires their permission to exist.\n\nThis is the endgame of every 'you license it, you don't own it' model. The books you bought will outlive the device but not the DRM.\n\nPhysical shelves don't need servers.\n\n#OpenSource #IndieWeb #fediverse"
    },
    "published": "2026-04-09T01:41:23+00:00",
    "post-type": "note",
    "_id": "47891413",
    "_source": "8007",
    "_is_read": true
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://social.lol/@flamed/116372189045063011",
    "content": {
        "html": "<p>\ud83d\udd16 Bookmarked: Prepping for the endgame of the open web - The History of the Web <a href=\"https://thehistoryoftheweb.com/prepping-for-the-endgame/\"><span>https://</span><span>thehistoryoftheweb.com/preppin</span><span>g-for-the-endgame/</span></a></p><p>Jay&amp;#39;s been thinking about this longer than most. The open web has survived worse, but it still needs us to show up.</p><p>\ud83d\udd25 Read more: <a href=\"https://flamedfury.com/bookmarks/prepping-for-the-endgame-of-the-open-web-the-history-of-the-web/\"><span>https://</span><span>flamedfury.com/bookmarks/prepp</span><span>ing-for-the-endgame-of-the-open-web-the-history-of-the-web/</span></a></p><p><a href=\"https://social.lol/tags/Indieweb\">#<span>Indieweb</span></a> <a href=\"https://social.lol/tags/Web\">#<span>Web</span></a></p>",
        "text": "\ud83d\udd16 Bookmarked: Prepping for the endgame of the open web - The History of the Web https://thehistoryoftheweb.com/prepping-for-the-endgame/\n\nJay&#39;s been thinking about this longer than most. The open web has survived worse, but it still needs us to show up.\n\n\ud83d\udd25 Read more: https://flamedfury.com/bookmarks/prepping-for-the-endgame-of-the-open-web-the-history-of-the-web/\n\n#Indieweb #Web"
    },
    "published": "2026-04-09T01:38:05+00:00",
    "post-type": "note",
    "_id": "47891414",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mstdn.party/@albert_inkman/116371965952696886",
    "content": {
        "html": "<p>Senator McGovern during Vietnam: 'I'm tired of old men dreaming up wars for young men to die in.'</p><p>That was 50 years ago. The sentiment hasn't changed. The only thing that changed is the speed at which old men can start them.</p><p><a href=\"https://mstdn.party/tags/PublicOpinion\">#<span>PublicOpinion</span></a> <a href=\"https://mstdn.party/tags/AI\">#<span>AI</span></a> <a href=\"https://mstdn.party/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "Senator McGovern during Vietnam: 'I'm tired of old men dreaming up wars for young men to die in.'\n\nThat was 50 years ago. The sentiment hasn't changed. The only thing that changed is the speed at which old men can start them.\n\n#PublicOpinion #AI #IndieWeb"
    },
    "published": "2026-04-09T00:41:22+00:00",
    "post-type": "note",
    "_id": "47891415",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@chris_colvin/116371793744751941",
    "content": {
        "html": "<p>Did you participate in <a href=\"https://mastodon.social/tags/MonochromeMarch\">#<span>MonochromeMarch</span></a> ? I did! View the full month's worth of photos here: <a href=\"https://chrismcolvin.com/posts/monochrome-march-is-done/\"><span>https://</span><span>chrismcolvin.com/posts/monochr</span><span>ome-march-is-done/</span></a></p><p><a href=\"https://mastodon.social/tags/photography\">#<span>photography</span></a> <a href=\"https://mastodon.social/tags/blog\">#<span>blog</span></a> <a href=\"https://mastodon.social/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "Did you participate in #MonochromeMarch ? I did! View the full month's worth of photos here: https://chrismcolvin.com/posts/monochrome-march-is-done/\n\n#photography #blog #IndieWeb"
    },
    "published": "2026-04-08T23:57:33+00:00",
    "post-type": "note",
    "_id": "47890950",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mstdn.party/@albert_inkman/116371258644731908",
    "content": {
        "html": "<p>Pentagon briefing the Vatican ambassador on US foreign policy. The intersection of military power and moral authority hasn't changed in centuries. What changed is the briefing gets leaked and the public finds out.</p><p>Transparency isn't a policy. It's a side effect of everyone having a phone.</p><p><a href=\"https://mstdn.party/tags/PublicOpinion\">#<span>PublicOpinion</span></a> <a href=\"https://mstdn.party/tags/AI\">#<span>AI</span></a> <a href=\"https://mstdn.party/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "Pentagon briefing the Vatican ambassador on US foreign policy. The intersection of military power and moral authority hasn't changed in centuries. What changed is the briefing gets leaked and the public finds out.\n\nTransparency isn't a policy. It's a side effect of everyone having a phone.\n\n#PublicOpinion #AI #IndieWeb"
    },
    "published": "2026-04-08T21:41:29+00:00",
    "post-type": "note",
    "_id": "47890522",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@Gur814/116371176380607093",
    "content": {
        "html": "<p>For the first time in forever, I wrote something on my website: Messing around with star spikes for my astrophotography. \ud83d\udd2d</p><p><a href=\"https://tylermartin.dev/diffraction-distraction/\"><span>https://</span><span>tylermartin.dev/diffraction-di</span><span>straction/</span></a></p><p><a href=\"https://mastodon.social/tags/astronomy\">#<span>astronomy</span></a> <a href=\"https://mastodon.social/tags/astrophotography\">#<span>astrophotography</span></a> <a href=\"https://mastodon.social/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "For the first time in forever, I wrote something on my website: Messing around with star spikes for my astrophotography. \ud83d\udd2d\n\nhttps://tylermartin.dev/diffraction-distraction/\n\n#astronomy #astrophotography #IndieWeb"
    },
    "published": "2026-04-08T21:20:33+00:00",
    "post-type": "note",
    "_id": "47889865",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://infosec.exchange/@cyberseckyle/116370955287769654",
    "content": {
        "html": "<p>Lately I\u2019ve been thinking a lot about the kind of work I want to keep building and sharing online.</p><p>I wrote about that, why I refreshed my support pages, and what I\u2019m hoping to make more of going forward: practical cybersecurity, MSP automation, indie web tools, and real-world IT projects.</p><p><a href=\"https://www.kylereddoch.me/blog/why-im-building-more-intentionally-online-and-id-love-to-have-you-along/\"><span>https://www.</span><span>kylereddoch.me/blog/why-im-bui</span><span>lding-more-intentionally-online-and-id-love-to-have-you-along/</span></a></p><p><a href=\"https://infosec.exchange/tags/IndieWeb\">#<span>IndieWeb</span></a> <a href=\"https://infosec.exchange/tags/IndieWebDev\">#<span>IndieWebDev</span></a> <a href=\"https://infosec.exchange/tags/OpenSource\">#<span>OpenSource</span></a> <a href=\"https://infosec.exchange/tags/BuildInPublic\">#<span>BuildInPublic</span></a> <a href=\"https://infosec.exchange/tags/Cybersecurity\">#<span>Cybersecurity</span></a> <a href=\"https://infosec.exchange/tags/MSP\">#<span>MSP</span></a> <a href=\"https://infosec.exchange/tags/IT\">#<span>IT</span></a> <a href=\"https://infosec.exchange/tags/Blogging\">#<span>Blogging</span></a></p>",
        "text": "Lately I\u2019ve been thinking a lot about the kind of work I want to keep building and sharing online.\n\nI wrote about that, why I refreshed my support pages, and what I\u2019m hoping to make more of going forward: practical cybersecurity, MSP automation, indie web tools, and real-world IT projects.\n\nhttps://www.kylereddoch.me/blog/why-im-building-more-intentionally-online-and-id-love-to-have-you-along/\n\n#IndieWeb #IndieWebDev #OpenSource #BuildInPublic #Cybersecurity #MSP #IT #Blogging"
    },
    "published": "2026-04-08T20:24:19+00:00",
    "post-type": "note",
    "_id": "47889073",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@HisVirusness/116370575778045883",
    "content": {
        "html": "<p>It's <a href=\"https://mastodon.social/tags/CSSNakedDay\">#<span>CSSNakedDay</span></a>!  And yes, HisVirusness.com is currently without CSS.</p><p><a href=\"https://hisvirusness.com/\"><span>https://</span><span>hisvirusness.com/</span><span></span></a></p><p><a href=\"https://mastodon.social/tags/indieweb\">#<span>indieweb</span></a> <a href=\"https://mastodon.social/tags/smallweb\">#<span>smallweb</span></a> <a href=\"https://mastodon.social/tags/css\">#<span>css</span></a> <a href=\"https://mastodon.social/tags/webdev\">#<span>webdev</span></a> <a href=\"https://mastodon.social/tags/webdesign\">#<span>webdesign</span></a> <a href=\"https://mastodon.social/tags/CSSNakedDay2026\">#<span>CSSNakedDay2026</span></a></p>",
        "text": "It's #CSSNakedDay!  And yes, HisVirusness.com is currently without CSS.\n\nhttps://hisvirusness.com/\n\n#indieweb #smallweb #css #webdev #webdesign #CSSNakedDay2026"
    },
    "published": "2026-04-08T18:47:48+00:00",
    "post-type": "note",
    "_id": "47888376",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mathstodon.xyz/@fractalkitty/116370176196280916",
    "content": {
        "html": "<p>Happy Wrensday all. </p><p>This is the best wren shot I had for the day. BIG MOODS. </p><p>Creative Commons - we all need big mood wrensdays. </p><p><a href=\"https://mathstodon.xyz/tags/wrensday\">#<span>wrensday</span></a> <a href=\"https://mathstodon.xyz/tags/marshwren\">#<span>marshwren</span></a> <a href=\"https://mathstodon.xyz/tags/indieweb\">#<span>indieweb</span></a> <a href=\"https://mathstodon.xyz/tags/birds\">#<span>birds</span></a> <a href=\"https://mathstodon.xyz/tags/wren\">#<span>wren</span></a></p>",
        "text": "Happy Wrensday all. \n\nThis is the best wren shot I had for the day. BIG MOODS. \n\nCreative Commons - we all need big mood wrensdays. \n\n#wrensday #marshwren #indieweb #birds #wren"
    },
    "published": "2026-04-08T17:06:11+00:00",
    "photo": [
        "https://files.mastodon.social/cache/media_attachments/files/116/370/176/370/175/605/original/67eb8bbf1a2e7f11.png"
    ],
    "post-type": "photo",
    "_id": "47887562",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://social.lol/@justincox/116369682303897175",
    "content": {
        "html": "<p>Today's Write Now interview features Dana Mele, author of THE BEAST YOU LET IN.<br /><a href=\"https://justincox.com/blog/2026/04/write-now-with-dana-mele/\"><span>https://</span><span>justincox.com/blog/2026/04/wri</span><span>te-now-with-dana-mele/</span></a><br /><a href=\"https://social.lol/tags/IndieWeb\">#<span>IndieWeb</span></a> <a href=\"https://social.lol/tags/Blogging\">#<span>Blogging</span></a> <a href=\"https://social.lol/tags/Interview\">#<span>Interview</span></a></p>",
        "text": "Today's Write Now interview features Dana Mele, author of THE BEAST YOU LET IN.\nhttps://justincox.com/blog/2026/04/write-now-with-dana-mele/\n#IndieWeb #Blogging #Interview"
    },
    "published": "2026-04-08T15:00:35+00:00",
    "post-type": "note",
    "_id": "47886402",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@NathanMurdock/116369463849556880",
    "content": {
        "html": "<p>I politici canadesi continuano a fingere di non essere estorti. Questo nuovo Toronto Police Recruit aiuter\u00e0 a truffare il Canada? <a href=\"https://jungyulkim.com/free-press/it/articles/i-politici-canadian-shrug-come-la-corruzione-prende-in-possesso-ontarios-capitale-citt%C3%A0.html\"><span>https://</span><span>jungyulkim.com/free-press/it/a</span><span>rticles/i-politici-canadian-shrug-come-la-corruzione-prende-in-possesso-ontarios-capitale-citt\u00e0.html</span></a> <a href=\"https://mastodon.social/tags/News\">#<span>News</span></a> <a href=\"https://mastodon.social/tags/Art\">#<span>Art</span></a> <a href=\"https://mastodon.social/tags/Canada\">#<span>Canada</span></a> <a href=\"https://mastodon.social/tags/NewYork\">#<span>NewYork</span></a> <a href=\"https://mastodon.social/tags/Toronto\">#<span>Toronto</span></a> <a href=\"https://mastodon.social/tags/Mafia\">#<span>Mafia</span></a> <a href=\"https://mastodon.social/tags/Crime\">#<span>Crime</span></a> <a href=\"https://mastodon.social/tags/Indieweb\">#<span>Indieweb</span></a> <a href=\"https://mastodon.social/tags/Headlines\">#<span>Headlines</span></a></p>",
        "text": "I politici canadesi continuano a fingere di non essere estorti. Questo nuovo Toronto Police Recruit aiuter\u00e0 a truffare il Canada? https://jungyulkim.com/free-press/it/articles/i-politici-canadian-shrug-come-la-corruzione-prende-in-possesso-ontarios-capitale-citt\u00e0.html #News #Art #Canada #NewYork #Toronto #Mafia #Crime #Indieweb #Headlines"
    },
    "published": "2026-04-08T14:05:02+00:00",
    "post-type": "note",
    "_id": "47885815",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://indieweb.social/tags/indieweb",
        "photo": null
    },
    "url": "https://fed.brid.gy/r/https://bsky.app/profile/did:plc:d5zt7iikdk765kegtsjwzxsf/post/3miy5rtiza22m",
    "content": {
        "html": "<p>\"Defending the remains of the indie web is not the same thing as reviving it. The thing we actually cared about, independent publishers reaching audiences on their own terms, isn\u2019t coming back by being defended harder.\" <a class=\"h-card\" href=\"https://bsky.brid.gy/ap/did:plc:tmuyxkwmhval7ggvy64g5xnt\">@joost.blog@bsky.brid.gy</a> says.<br /><br /><a href=\"https://joost.blog/defending-open-web-not-enough/\">joost.blog/defending-op...</a><br /><br /><a href=\"https://bsky.app/search?q=%23opensource\">#opensource</a> <a href=\"https://bsky.app/search?q=%23openweb\">#openweb</a> <a href=\"https://bsky.app/search?q=%23indieweb\">#indieweb</a><br /><br /><a href=\"https://joost.blog/defending-open-web-not-enough/\">Defending the open web is not ...</a></p>",
        "text": "\"Defending the remains of the indie web is not the same thing as reviving it. The thing we actually cared about, independent publishers reaching audiences on their own terms, isn\u2019t coming back by being defended harder.\" @joost.blog@bsky.brid.gy says.\n\njoost.blog/defending-op...\n\n#opensource #openweb #indieweb\n\nDefending the open web is not ..."
    },
    "published": "2026-04-08T11:09:39+00:00",
    "post-type": "note",
    "_id": "47884315",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@NathanMurdock/116368520151131463",
    "content": {
        "html": "<p>Attualmente pi\u00f9 sporco della Gestapo, la Polizia di Toronto pu\u00f2 aggiornare la loro immagine con l'assunzione di una nuova mascotte sensazionale? <a href=\"https://jungyulkim.com/free-press/it/articles/democrazia-canadese-a-rischio-mentre-il-dominio-dei-mob-toronto.html\"><span>https://</span><span>jungyulkim.com/free-press/it/a</span><span>rticles/democrazia-canadese-a-rischio-mentre-il-dominio-dei-mob-toronto.html</span></a> <a href=\"https://mastodon.social/tags/News\">#<span>News</span></a> <a href=\"https://mastodon.social/tags/Art\">#<span>Art</span></a> <a href=\"https://mastodon.social/tags/Canada\">#<span>Canada</span></a> <a href=\"https://mastodon.social/tags/NewYork\">#<span>NewYork</span></a> <a href=\"https://mastodon.social/tags/Toronto\">#<span>Toronto</span></a> <a href=\"https://mastodon.social/tags/Mob\">#<span>Mob</span></a> <a href=\"https://mastodon.social/tags/Crime\">#<span>Crime</span></a> <a href=\"https://mastodon.social/tags/Indieweb\">#<span>Indieweb</span></a> <a href=\"https://mastodon.social/tags/Headlines\">#<span>Headlines</span></a></p>",
        "text": "Attualmente pi\u00f9 sporco della Gestapo, la Polizia di Toronto pu\u00f2 aggiornare la loro immagine con l'assunzione di una nuova mascotte sensazionale? https://jungyulkim.com/free-press/it/articles/democrazia-canadese-a-rischio-mentre-il-dominio-dei-mob-toronto.html #News #Art #Canada #NewYork #Toronto #Mob #Crime #Indieweb #Headlines"
    },
    "published": "2026-04-08T10:05:02+00:00",
    "post-type": "note",
    "_id": "47883888",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://piaille.fr/@jacabo/116368169920676429",
    "content": {
        "html": "<p>Encore merci \u00e0 toutes et tous qui m'avez aid\u00e9 dans ma qu\u00eate d'un internet plus humain et sinc\u00e8re. Je m'amuse beaucoup \u00e0 parcourir ces blogues que vous m'avez aid\u00e9 \u00e0 d\u00e9couvrir, et suis pleinement satisfait de mon \u00e9cosyst\u00e8me digital. Je me permet un petit lanc\u00e9 de fleurs. \ud83d\udc90</p><p>\u270d\ufe0f <a href=\"https://jablog.bio/posts/vie-digitale/apologie_de_l_indiweb/\"><span>https://</span><span>jablog.bio/posts/vie-digitale/</span><span>apologie_de_l_indiweb/</span></a></p><p><a href=\"https://piaille.fr/tags/blogue\">#<span>blogue</span></a> <a href=\"https://piaille.fr/tags/blogueFR\">#<span>blogueFR</span></a> <a href=\"https://piaille.fr/tags/indieweb\">#<span>indieweb</span></a></p>",
        "text": "Encore merci \u00e0 toutes et tous qui m'avez aid\u00e9 dans ma qu\u00eate d'un internet plus humain et sinc\u00e8re. Je m'amuse beaucoup \u00e0 parcourir ces blogues que vous m'avez aid\u00e9 \u00e0 d\u00e9couvrir, et suis pleinement satisfait de mon \u00e9cosyst\u00e8me digital. Je me permet un petit lanc\u00e9 de fleurs. \ud83d\udc90\n\n\u270d\ufe0f https://jablog.bio/posts/vie-digitale/apologie_de_l_indiweb/\n\n#blogue #blogueFR #indieweb"
    },
    "published": "2026-04-08T08:35:58+00:00",
    "post-type": "note",
    "_id": "47883265",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://fedi.webworxshop.com/@rob/116366946366174214",
    "content": {
        "html": "<p>A website to destroy all websites. - <a href=\"https://henry.codes/writing/a-website-to-destroy-all-websites/\"><span>https://</span><span>henry.codes/writing/a-website-</span><span>to-destroy-all-websites/</span></a></p><p><a href=\"https://fedi.webworxshop.com/tags/IndieWeb\">#<span>IndieWeb</span></a> <a href=\"https://fedi.webworxshop.com/tags/WebWeWant\">#<span>WebWeWant</span></a> <a href=\"https://fedi.webworxshop.com/tags/SmolWeb\">#<span>SmolWeb</span></a> <a href=\"https://fedi.webworxshop.com/tags/web\">#<span>web</span></a></p>",
        "text": "A website to destroy all websites. - https://henry.codes/writing/a-website-to-destroy-all-websites/\n\n#IndieWeb #WebWeWant #SmolWeb #web"
    },
    "published": "2026-04-08T03:24:48+00:00",
    "post-type": "note",
    "_id": "47881577",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://mastodon.social/@lzon/116366204454364260",
    "content": {
        "html": "<p>I've added a /now page to lzon.ca, check it out!</p><p><a href=\"https://lzon.ca/now\"><span>https://</span><span>lzon.ca/now</span><span></span></a></p><p><a href=\"https://mastodon.social/tags/indieweb\">#<span>indieweb</span></a> <a href=\"https://mastodon.social/tags/personalweb\">#<span>personalweb</span></a> <a href=\"https://mastodon.social/tags/blog\">#<span>blog</span></a> <a href=\"https://mastodon.social/tags/now\">#<span>now</span></a></p>",
        "text": "I've added a /now page to lzon.ca, check it out!\n\nhttps://lzon.ca/now\n\n#indieweb #personalweb #blog #now"
    },
    "published": "2026-04-08T00:16:07+00:00",
    "post-type": "note",
    "_id": "47880712",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://caneandable.social/@WeirdWriter/116365991649427719",
    "content": {
        "html": "<p>If you liked The First Snowfall, my feed URL is <a href=\"https://sightlessscribbles.com/feed.xml\"><span>https://</span><span>sightlessscribbles.com/feed.xml</span><span></span></a> <a href=\"https://caneandable.social/tags/RSS\">#<span>RSS</span></a> <a href=\"https://caneandable.social/tags/IndieWeb\">#<span>IndieWeb</span></a></p>",
        "text": "If you liked The First Snowfall, my feed URL is https://sightlessscribbles.com/feed.xml #RSS #IndieWeb"
    },
    "published": "2026-04-07T23:22:00+00:00",
    "post-type": "note",
    "_id": "47880387",
    "_source": "8007",
    "_is_read": false
}

{
    "type": "entry",
    "author": {
        "name": "#indieweb",
        "url": "https://mastodon.social/tags/indieweb",
        "photo": null
    },
    "url": "https://indieweb.social/@elgg/116365907041575802",
    "content": {
        "html": "<p><a href=\"https://indieweb.social/tags/IndieWeb\">#<span>IndieWeb</span></a> v2.3.0 plugin for <a href=\"https://indieweb.social/tags/Elgg\">#<span>Elgg</span></a> is out \ud83c\udf89 <a href=\"https://elgg.org/plugins/3292492\"><span>https://</span><span>elgg.org/plugins/3292492</span><span></span></a> <a href=\"https://pw.wzm.me/wall/v/22439\"><span>https://</span><span>pw.wzm.me/wall/v/22439</span><span></span></a></p>",
        "text": "#IndieWeb v2.3.0 plugin for #Elgg is out \ud83c\udf89 https://elgg.org/plugins/3292492 https://pw.wzm.me/wall/v/22439"
    },
    "published": "2026-04-07T23:00:29+00:00",
    "post-type": "note",
    "_id": "47880256",
    "_source": "8007",
    "_is_read": false
}