On 13 March 2014 00:23, Maurice McCarthy wrote: > On the typo http://www.openbsd.org/faq//faq1.html an extra "faq/" is placed > ... > where it should not be.
It isn't really *placed*. If you look at the HTML source, you'll see that the links that (only) *seem* to be "acting up" in connection with the mistyped URL are just ordinary relative links; e.g.: | Our | <a href="../goals.html">goals</a> place emphasis on correctness, | <a href="../security.html">security</a>, standardization, and | <a href="../plat.html">portability</a>. It's just that your browser (and my Firefox) seems to --in this context at least-- interpret the "//" as an extra level in the hierarchy, so the "start from www.openbsd.org/faq/ and go one level up to reach www.openbsd.org/" seems to become "start from www.openbsd.org/faq// and go one level up to reach www.openbsd.org/faq/" (which doesn't have e.g. a goals.html). The inconsistency arises because on the one hand, the "//" is accepted as equivalent to "/" (which is why you're getting a page at all with the mistyped URL), but then on the other hand, the "//" is parsed as two hierarchy levels. So "//" counts as 1 on the way *down* the hierarchy, but it counts as 2 on the way back *up*. I'm not actually sure if this behaviour is canonical, and/or whether it's a bug or not, either in Firefox or (also) in the HTTPD. To my naive mind making assumptions that are based on bugger all, the "//" ought to take you back to the root, but I haven't read the RFC/spec. Maybe someone else knows this off the top of their head? regards, --ropers PS: Okay, so I have at least skimmed parts of https://tools.ietf.org/html/rfc3986#section-3 - but specifically as the question how //s ought to be treated, I'm none the wiser. Apparently the only place the RFC really envisages //s is in front of the authority (domain name part), i.e.after http: or similar. But then the RFC doesn't strictly say that //s were illegal in any other place. If anyone else knows this, I'd be much obliged for cluebat ministrations.
