TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Trailing slashes on URLs: Contentious or settled?

95 点作者 josephscott超过 3 年前

17 条评论

brabel超过 3 年前
This is one of those &quot;made up problems&quot; as it only exists because you insist in doing magic, i.e. mapping &#x2F;foo to either &#x2F;foo&#x2F;index.html or &#x2F;foo.html.<p>I am guilty myself, because we need to do things that match expectation of users, but this problem simply disappears if you stop doing magic.<p>So, the real question is, what &quot;magic&quot; do you prefer?<p>My implementation was, when given a trailing slash, check if the recource is a directory (as this is what the trailing slash signifies) and use the convention of loading the index.html file at that directory if it is. If it&#x27;s not a directory, then it&#x27;s a 404.<p>If there&#x27;s no trailing slash, try to load the file with the equivalent extension to the Accept content-type header. So, if the client wants JSON, you try &#x2F;foo.json for the path &#x2F;foo. If client requests HTML, try &#x2F;foo.html.
评论 #30099863 未加载
评论 #30099357 未加载
评论 #30099942 未加载
neilwilson超过 3 年前
Very much required if you want to use relative URL calculations.<p>Stumbled across this in Go yesterday<p>Compare a relativeUrl ref from &#x27;<a href="http:&#x2F;&#x2F;localhost&#x2F;1.0" rel="nofollow">http:&#x2F;&#x2F;localhost&#x2F;1.0</a>&#x27; vs. &#x27;<a href="http:&#x2F;&#x2F;localhost&#x2F;1.0&#x2F;" rel="nofollow">http:&#x2F;&#x2F;localhost&#x2F;1.0&#x2F;</a>&#x27;<p>e.g. <a href="https:&#x2F;&#x2F;play.golang.com&#x2F;p&#x2F;AsUSx6bRWn6" rel="nofollow">https:&#x2F;&#x2F;play.golang.com&#x2F;p&#x2F;AsUSx6bRWn6</a>
评论 #30097585 未加载
评论 #30099321 未加载
评论 #30097637 未加载
评论 #30097728 未加载
Flimm超过 3 年前
Trailing slashes are terrible in right-to-left contexts. The trailing slash suddenly teleports to the beginning of the URL visually. Take this example:<p><pre><code> &lt;div dir=&quot;rtl&quot;&gt; http:&#x2F;&#x2F;example.com&#x2F;example&#x2F; &lt;&#x2F;div&gt; </code></pre> This displays as if it were the string:<p><pre><code> &#x2F;http:&#x2F;&#x2F;example.com&#x2F;example </code></pre> It&#x27;s awful. Much better if everything was configured to leave off the trailing slash.
评论 #30088158 未加载
评论 #30094912 未加载
floatingatoll超过 3 年前
Machines will occasionally add trailing slashes, and they will rarely remove them.<p>Users will occasionally add trailing slashes, and will occasionally remove trailing slashes.<p>So as long as $PATH and $PATH&#x2F; map to the same outcome, and redirection from the ‘wrong’ one to the ‘right’ one to the other uses a 307&#x2F;308 to allow non-GET methods to redirect, then everything will always work out okay.<p>Varying from that recipe in any regard is a source of pain and trauma in every complicated ingress scenario I’ve worked with for twenty years. (Dispatch methods, regular expressions, exact string matches, all of them.)
评论 #30099583 未加载
harshreality超过 3 年前
The common redirects that most webservers do are:<p>&#x2F;path to &#x2F;path&#x2F; *if and only if &#x2F;path is a directory in the filesystem*<p>&#x2F;path&#x2F; to &#x2F;path&#x2F;index.htm[l] (usually the default of some indexing module, often configurable so you or some other module can add index.php etc.)<p>Redirects can be internal or external. Nginx, for instance, does step 1 via an external redirect and step 2 via an internal redirect, so the final url displayed in the browser when the input was &#x2F;path would end up as &#x2F;path&#x2F; but not &#x2F;path&#x2F;index.html even if that&#x27;s what&#x27;s being served. You can, however, combine both steps into one and make it an internal redirect by doing something like &quot;try_files $uri&#x2F;index.html ...&quot;<p>It&#x27;s <i>not</i> standard to rewrite:<p>&#x2F;path to &#x2F;path.html<p>But almost any webserver can be configured to do so, and various websites and web apps may have reasons for doing that. Then it&#x27;s merely a matter of understanding the webserver&#x27;s internal configuration rule order to determine whether it&#x27;ll redirect &#x2F;path preferentially to &#x2F;path&#x2F;index.html or to &#x2F;path.html<p>There&#x27;s no universal right or wrong. Every one of those paths is different, and webservers can choose which to rewrite to which other.
chrismorgan超过 3 年前
&gt; <i>SEO: if your content exists at two (or more!) distinct URL endpoints, it is a SEO no-no.</i> […] <i>You</i> need <i>redirects.</i><p>Or you could just only serve it from one of the two URLs and let the other 404. (Yeah, static file servers don’t tend to be fond of working this way, but it’s not an unreasonable option if you’re forming a matrix of fundamental possibilities. And indeed, in the analysis, it’s what half the servers do at least some of the time; and it’s what all standard static file serving software that I know does out of the box.)<p>&gt; <i>Vercel, Render, and Azure Static Web Apps: slashless &#x2F;resource returns content</i> [from resource&#x2F;index.html] <i>but without redirects, resulting in multiple endpoints for the same content.</i><p>This is <i>obviously</i> Wrong with a capital W because of how it breaks relative URLs in the file. Surely it should just be considered a bug and fixed (probably to redirect to &#x2F;resource&#x2F;)?<p>&gt; <i>Almost everyone agrees that &#x2F;resource should return content from resource.html</i><p>This is a biased view because you’re only considering mildly-opinionated static file servers and their configuration. If you’re serving it yourself with things like nginx or Apache httpd, you <i>won’t</i> get this out of the box and must opt into it. (No idea about others like Caddy.)<p>&gt; (When both resource.html and resource&#x2F;index.html are present and &#x2F;resource&#x2F; is requested.) <i>Netlify redirects to &#x2F;resource instead.</i><p>I say of this too that it is obviously a bug. Netlify isn’t just taking an opinionated stance, it’s doing what is fairly unequivocally the Wrong Thing.
评论 #30096120 未加载
评论 #30098690 未加载
评论 #30096087 未加载
newsbinator超过 3 年前
To me, conceptually, trailing slashes are as valuable as trailing commas in English. They&#x27;re separators, and on the end there&#x27;s nothing left to separate.
评论 #30081347 未加载
评论 #30094644 未加载
zaphar超过 3 年前
If you automatically serve an index.html when the url is &#x2F;resource&#x2F; I presume you would also serve the same page at &#x2F;resource&#x2F;index.html which in practice means that you are again in same content at two different URLs land. I lean more toward the principle of be permissive in what you accept principle here and would serve the same content for: &#x2F;resource &#x2F;resource&#x2F; and &#x2F;resource&#x2F;index.html if presented with the url without doing a redirect. But in all my links or documentation standardize on just one of those. which in practice means that for most crawlers you&#x27;ll only have one effective URL for the content, while still providing an experience that isn&#x27;t annoying for users if they happen to type in a trailing slash for the browser.
评论 #30094299 未加载
评论 #30094184 未加载
thraxil超过 3 年前
I&#x27;ve used Django for a long time. Django defaults to adding trailing slashes to make relative URLs easier to implement correctly. I&#x27;ve always found that sensible and useful. I&#x27;ve recently been putting some APIs behind GCP&#x27;s API Gateway and discovered that their OpenAPI implementation strips trailing slashes: <a href="https:&#x2F;&#x2F;cloud.google.com&#x2F;endpoints&#x2F;docs&#x2F;openapi&#x2F;openapi-limitations#url_path_templating" rel="nofollow">https:&#x2F;&#x2F;cloud.google.com&#x2F;endpoints&#x2F;docs&#x2F;openapi&#x2F;openapi-limi...</a><p>So... I guess no more trailing slashes for me.
jillesvangurp超过 3 年前
Trailing slashes should be optional and the server response should be the same regardless of their presence. At least, that&#x27;s how I expect my applications to behave. It&#x27;s the principle of the least amount of surprise. You might be pleasantly surprised that it works if you add the slash as opposed to be mildly annoyed when it gives you a 404. Requiring the slash would be very surprising. The least surprising is that they both work the same way. I see no technical reason for them to behave differently.<p>Some web-servers do this and others require fiddling with to get them to behave that way. But ultimately. the slash is just a separator and not semantically relevant. It&#x27;s like many languages now allowing trailing commas in lists. It&#x27;s convenient. The comma does not add an extra element.<p>One place where this comes up in practice is with specifying base URIs in e.g. configuration files. Somewhere else, this base URI is consumed to construct a full URI using a suffix that may or may not have a leading slash.<p>If your base URL is <a href="http:&#x2F;&#x2F;foo(&#x2F;)" rel="nofollow">http:&#x2F;&#x2F;foo(&#x2F;)</a> and you want to append (&#x2F;)bar, you might end up with <a href="http:&#x2F;&#x2F;foobar" rel="nofollow">http:&#x2F;&#x2F;foobar</a>, <a href="http:&#x2F;&#x2F;foo&#x2F;&#x2F;bar" rel="nofollow">http:&#x2F;&#x2F;foo&#x2F;&#x2F;bar</a>, <a href="http:&#x2F;&#x2F;foo&#x2F;bar" rel="nofollow">http:&#x2F;&#x2F;foo&#x2F;bar</a> depending on what people do on both sides. Or those three with a trailing slash. There is no right answer.<p>The only sane behavior that follows the principle of the least amount of surprise is to make sure that base uri and suffix will be separated by exactly one slash and assume nothing about the presence of leading or trailing slashes. That way, nothing will break or behave unexpectedly if people add or omit a trailing or leading slash.
krobelus超过 3 年前
The lack of canonicalization has caused us tons of trouble on an Angular app. Check out <a href="https:&#x2F;&#x2F;symflower.com&#x2F;en&#x2F;company&#x2F;blog&#x2F;2021&#x2F;path-independent-angular&#x2F;" rel="nofollow">https:&#x2F;&#x2F;symflower.com&#x2F;en&#x2F;company&#x2F;blog&#x2F;2021&#x2F;path-independent-...</a> - you&#x27;ll be laughing (or crying)
archi42超过 3 年前
&gt; The NearlyFreeSpeech.NET member site you are attempting to reach appears to be temporarily unavailable.<p><a href="https:&#x2F;&#x2F;archive.is&#x2F;XvE2X" rel="nofollow">https:&#x2F;&#x2F;archive.is&#x2F;XvE2X</a>
rascul超过 3 年前
&#x2F;path is different from &#x2F;path&#x2F;. They can serve the same content depending on web server config, though. For an example of how they can be different, check <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newest" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newest</a> vs <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newest&#x2F;</a>.
teddyh超过 3 年前
You know what’s better than the “resource” URL leading to resource&#x2F;index.html? Having the “resource” URL lead to plain resource.html. Then you can still have a directory named “resource” and any relative links in resource.html to “resource&#x2F;thing” (to reach resource&#x2F;thing.html) will feel natural, as “thing” is indeed in a subdirectory.<p>(Apache supports this using “MultiviewsMatch”.)
account42超过 3 年前
I like to use &#x2F;resource&#x2F; traling slashes only if the page is a mere index of pages in that directory. If the page has its own content I use &#x2F;resource without a trailing slash, even if there is a matching directory, because I think it looks prettier - but that is of course purely a matter of taste.
mjul超过 3 年前
When in doubt, check the spec.<p>In this case it is in RFC 2396 &quot;Uniform Resource Identifiers (URI): Generic Syntax&quot; [1].<p>In Section 3 you find this. The forward stroke (&quot;slash&quot;) is a separator:<p><pre><code> URI that are hierarchical in nature use the slash &quot;&#x2F;&quot; character for separating hierarchical components. </code></pre> [1] <a href="http:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc2396.txt" rel="nofollow">http:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc2396.txt</a>
评论 #30099851 未加载
_zooted超过 3 年前
&gt; SEO: if your content exists at two (or more!) distinct URL endpoints, it is a SEO no-no. SE-no-no. SEO-apolo-graphql-anton-ohno (I apologize for nothing). <i>Ahem</i>. You need redirects.<p>Probably not.
评论 #30097002 未加载