Chris's Wiki :: blog/web/DeFactoQueryParameters Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/DeFactoQueryParameters?atomcommentsDWiki2020-09-09T20:29:45ZRecent comments in Chris's Wiki :: blog/web/DeFactoQueryParameters.By Anonymous on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:7d3cd3a0c653f0c322f9f92c04a99b00866c71a4Anonymous<div class="wikitext"><p>@Andy: Actually, these days (some) people argue that, in hindsight, Postel was wrong.</p>
<p><a href="https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03.html">https://tools.ietf.org/id/draft-thomson-postel-was-wrong-03.html</a></p>
</div>2020-09-09T20:29:45ZBy Andy on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:61ed3d35722af3444e7638094a8bf790d8df2fc6Andy<div class="wikitext"><p>The internet was designed with Postel's law (be conservative in what you send and liberal in what you accept). The web was designed with this as well. Early on, the internet designers learned it's better to be liberal in what you accept (disregarding extras like url query params the code doesn't use)...strictly validating makes code more brittle. It's not a fault, it's a feature that has enabled interoperability for decades.</p>
</div>2020-09-08T20:42:27ZBy Just a guy on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:9370e6a6a18955f017df124f1ad1f7d87e43e9f0Just a guy<div class="wikitext"><p>I believe the ?s=NN parameter that you mention is a Twitter thing. I can't find a link, but on twitter when you share a link they add the s parameter. </p>
<p>From what I can remember, the value of the parameter is determined by the type of twitter client that you shared from. For example, twitter web, twitter for android, twitter for iOS, tweetDeck, etc.</p>
</div>2020-09-08T08:18:56ZBy using_linux on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:4a359a6d43ab797dff510c1b486249d3a16c7f15using_linux<div class="wikitext"><p>I agree with the redirect route. It may help to think of these URIs as spelling errors (as in Apache's mod_speling) or other clear but fixable errors (like the lack of a trailing slash, when the server clearly only gave out links to this resource with a slash at the end).</p>
<p>For technical audiences, a 404 with a `Refresh: 10; URL=the-fixed-one` could be helpful, with a message like "Whoever gave you this link put garbage on it, you will be redirected to what we hope is the intended page (but please nag who gave you that link)".</p>
</div>2020-09-08T07:14:07ZBy Aristotle Pagaltzis on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:b4a139d4e9ce7ea35ccf10ee2c1bcf2efd4a944dAristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>(Argh. <code>s/You shouldn’t den/&y/</code> …)</p>
</div>2020-09-08T04:32:15ZBy Aristotle Pagaltzis on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:01d9c6f27e510b41128468929d1480b3f789da94Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>You shouldn’t den requests with junk in the URL for reasons similar to why you shouldn’t serve XHTML. If a visitor shows up with junk attached to the URL, it’s almost always someone else who attached it for the visitor to carry along upon clicking the link. Denying such a request affects the visitor, but not whoever sent them, so it punishes an innocent party who has no relevant power to do something about it (they can edit their address bar but generally not the link they clicked on), while failing to convey any signal to the offending party.</p>
<p>However – visitors will propagate what’s in their address bar if they find the page interesting, and that includes any junk. So I came to suggest what 193.219.181.242 already did – redirecting them to clean up their URLs. Being helpful to visitors does not mean being forced to open up room for piggy-back pass-through tracking beacons in your URL space to the people sending you those visitors. (That’s aside from all the other undesirable effects of having multiple URLs for the same page, like making your logs harder to analyse, making your social link shares harder to track, etc.)</p>
</div>2020-09-08T04:30:45ZBy Andy on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:75b0b47e31140c926230f3d8e78e3f1992e16267Andyhttps://bitfolk.com/<div class="wikitext"><p>Could it also be for cache busting? i.e. add a random GET parameter and value, make sure to get the most recent version of content to generate a preview or something of the link?</p>
</div>2020-09-07T14:23:36ZFrom 193.219.181.242 on /blog/web/DeFactoQueryParameterstag:CSpace:blog/web/DeFactoQueryParameters:acba3c986cbc86b71ad05abfe5cc1b4ac790786eFrom 193.219.181.242<div class="wikitext"><p>I think sites should instead accept the requests with parameters... and 301 redirect them to the canonical URL without parameters. (Or use JS history.pushState() to the same effect.) This would at least ensure that the weird Analytics garbage does not propagate through further re-shares, or into people's bookmarks, and the browser's address bar looks nice as well.</p>
</div>2020-09-07T04:40:05Z