How come some site urls do not include a file extension?

折月煮酒 提交于 2019-12-17 06:08:13

问题


I was browsing the internet and noticed, YouTube, for example, contains a URL like this to denote a video page: http://www.youtube.com/watch?v=gwS1tGLB0vc.

My site uses a URL like this for a topic page: http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc.

The difference is, if you haven't already noticed that on youtube, there is no file extension for their watch page, so I am wondering, why do some sites not use file extensions and what use does it serve?


回答1:


File extensions are not used because of the idea that URIs (and therefore URLs) should be independent of implementation - if you want to access George W. Bush's addresses, you should be able to go to http://www.whitehouse.gov/presidents/georgewbush/addresses (for example). Whether the White House's servers are using PHP or Python or Perl doesn't matter to the end-user, so they shouldn't see it. The end-user doesn't care how the page was generated, because all web languages output the same HTML, CSS, and the like, and they're just viewing the page in their web browser.

Most web frameworks build this functionality in by default, precisely for this reason, and it can be accomplished regardless with URL rewriting in most webservers. This ideal is codified in the W3C Style Guide, which is undoubtedly a big proponent in this idea being so widely accepted. It's outlined in their guide, "Cool URIs Don't Change", which should clear things up if you still don't quite understand the reasoning here. That document is the go-to statement on the issue, and the de facto standard for frameworks.

It is worth noting that usually files that end up being downloaded (and sometimes data files used in AJAX) will still have their file extensions intact - http://example.com/song.mp3 or http://example.com/whitepaper.pdf - because they are intended to be saved to the end-user's computer, where file extensions matter. The extensions are not included for pages that are simply displayed - which is most pages.




回答2:


What you are seeing is an example of URL routing. Instead of pointing to a specific file (e.g. page.php), the server is using a routing table or configuration that directs the request to a handler that actually renders the html (or anything else depending on the mime type returned). If you notice, StackOverflow uses the same mechanism.




回答3:


Having or not having the extension is irrelevant. The browser acts on the MIME type returned by the server, not any extension used in the URL.




回答4:


When you ask 'Why?' are you asking for a technical reason or a design reason? Some people already answered the technical so I'll just comment on the design.

Basically it boils down to that url is an endpoint. It's a place that users/services need to get to. The extension is irrelevant in most cases. If a user is browsing the web and goes to http://site.com/users he is expecting a list of users. He doesn't care that it doesn't say .html or .php. And as a designer using those extensions doesn't really make sense. You want your app to make sense, and those extensions aren't really providing any insight that the user needs.

Times that you would want to use them were if you were creating a service that other applications would use. Then you could choose to use an extension to denote what kind of data one could expect to get back (.json, .xml, etc). There are people working on design guidelines and specs for this stuff, but it's all early

Basically those extensions are used because that's how web servers/clients worked by default. As web development has matured we started treating urls more professionally and tried to make them make sense to people reading/using them.




回答5:


While extensions don't matter to the browser, which just uses the headers passed along to it to determine what to display and how to display it, chances are they do matter on the server. For instance, your box could have both a php and a ruby interpreter installed, but your webserver has configuration files to map file extensions to MIME types. For instance, from Apache's php5.conf:

  AddType application/x-httpd-php .php .phtml .php3

which tells Apache that files ending in .php, .phtml and .php3 should be recognized as being PHP files.

However, since the extensions don't mean anything to the client, URLs often look "nicer" without them. In order to do so, technologies such as Apache's mod_rewrite can be used to "rewrite" client-land URLs to have meaning on the server.

For instance, you could set up mod_rewrite rules to rewrite a URL like http://yourblog.com/article/the-article-you-wrote (which looks nicer and is simpler to type and remember) to http://yourblog.com/articles.php?title=the-article-you-wrote, which Apache can use to properly route the request to your PHP script.




回答6:


The key is the HTTP response header's Content-Type field. Something like that:

HTTP 200 OK
Content-Type: video/flv
Content-Length: 102345

DATA-DATA-DATA-DATA-DATA-DATA-....

See also:

Content-Disposition: attachment; filename=genome.jpeg;
     modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

More details: http://en.wikipedia.org/wiki/MIME




回答7:


Well, file extensions aren't of any use on the internet. The browser doesn't care what the file extension is. You could serve a CSS file as .avi. So why not simply leave it out? This allows for shorter URLs.

Furthermore "rewriting" a url allows for more readable urls. You may not understand /categories.php?id=455 but you do /455-some-category.

If you want to do this yourself and are using Apache have a look at mod_rewrite.




回答8:


The url, should properly be considered part of the user-interface. As such, it should be designed to convey information about where the user is on the site, and the structure of the site.

A url such as:

mysite.com/sport/soccer/brazil_wins_worldcup

tells the user a lot about the structure of the site, and where he currently is. In contrast:

mysite.com/article.php?cateogry=12&articleid=371

is useless, instead it exposes irrelevant implementation-details such as which language is used to make the site, and what the id of that article is (likely stored in a database under that id)

In addition to this estethical argument (don't expose the user to irrelevant implementation-details) it also helps with making the site future-proof. Because if you never exposed your language of choice to begin with, you can later upgrade to Ruby or Python, without every link in the world that points to you, now being a 404.

Design urls to make sense for users, and to be future-proof.




回答9:


There are many possible answers to this. It's how your web application server(s) are configured that results in what your web browser is interpreting. There could be situations where you're using URL rewriting or routing, and as others have said, what handlers you're providing for requested URLs or extensions.

I could have a URL like "http://cory.com/this/really/doesnt/exist" and have it actually be pointing at "http://cory.com/this.does.exist.123" if I wanted to.




回答10:


The normal behavior of a web server is to map the requested URI path onto a file somewhere in the document root directory. So http://example.com/foo/bar is simply mapped onto /path/do/document/root/foo/bar. Additionally, the web server needs to know how to handle a file. This is often done by the file name extension. So files with the file name extension .php are handled by the PHP interpreter.

Now apart from this normal behavior, most web servers have features that allow to change both the mapping (i.e. URL rewriting) and the way how a file without a file name extension is handled.

In case of the Apache web server, the former can be done with mod_rewrite:

RewriteEngine on
RewriteRule ^/watch$ /watch.php

And the latter can be done with mod_mime:

<File watch>
    ForceType application/x-httpd-php
</File>

(Ok, actually this is not mod_mime feature but a core feature.)




回答11:


Rule: File extensions should not be included in URIs

On the Web, the period (.) character is commonly used to separate the file name and extension portions of a URI. A REST API should not include artificial file extensions in URIs to indicate the format of a message’s entity body. Instead, they should rely on the media type, as communicated through the Content-Type header, to determine how to process the body’s content.

(1)http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2)http://api.college.restapi.org/students/3248234/transcripts/2005/fall

(1)File extensions should not be used to indicate format preference. (2)REST API clients should be encouraged to utilize HTTP’s provided format selection mechanism, the Accept request header. references: design REST api rulebook




回答12:


below it what I use in my .htaccess to make the url still run correctly without the HTML or PHP extension.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.html -f

means that if the file with the specified name in the browser doesn't matching with directory (-d) or files(-f) in your webserver, then rewrite rule below

RewriteRule ^(.*)$ $1.html

i'm not sure how the below work but I think that after it rewrite with html and if it still not matching it then rewrite with php

RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php

if it still not matching it will be show 404 page.

you also can redirect 404 with the code below in .htaccess

ErrorDocument 404 /404.html

importance is the code is working in for my site.

http://mintnet.net/services

http://php.mintnet.net/home

those doesn't need the file-extension.




回答13:


"www.youtube.com/watch" is a directory of YouTube. So it can basically be written as "www.youtube.com/watch/" with the ending forward slash.



来源:https://stackoverflow.com/questions/3631153/how-come-some-site-urls-do-not-include-a-file-extension

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!