Talk:Uniform Resource Locator

From Wikipedia, the free encyclopedia

	Internet Portal This article is within the scope of WikiProject Internet, an attempt to better organise information in articles related to the Internet. For more information, visit the project page.
Start	This article has been rated as start-class on the class scale.
High	This article has been rated as high-importance on the importance scale.

Contents 1 Headline text 2 New RFC 3 Merging with URI 4 Pronunciation 5 Keep Both 6 HTTP cookie 7 RFC 1738 is now far obsolete 8 URL and IP address 9 URL of this article 10 mailto 11 Avoid self-references 12 Aug 2006 deletions and the future of this article 13 What was the purpose of the double-slash again? 14 delimiters 15 Is it okay? 16 'clean URLs with web services' 17 Fair use rationale for Image:Address Bar - Wikipedia.png

[edit] Headline text

"To go to the homepage one usually just enters the domain name such as www.wikipedia.org. Sometimes, and also in this case, "www." can be omitted: wikipedia.org."

In what cases can "www" be omitted ? What is the difference between URLs having "www" and those that don't ? Jay 07:19, 21 Mar 2004 (UTC)

The first part of an HTTP URL consists of the DNS host name plus the domain name. In the case of "http://www.wikipedia.org/", the host name is "www" and the domain name is "wikipedia.org". When you enter this in a web browser, the browser typically uses the DNS resolver on your system to determine the IP address of host "www" in domain "wikipedia.org". If the DNS servers for domain wikipedia.org define an IP address for "wikipedia.org" or an alias for wikipedia.org that uses that same IP address as "www.wikipedia.org", then the leading "www" is not required since it will resolve in DNS to the same IP address. The requirement for the leading "www" is entirely dependent on how DNS is configured for that domain.

---

Apart from the possibility of a name being available in the DNS, many browsers actually do a number of heuristical modifications to the URL if it doesn't lead anywhere. Typically, a TLD (such as .com, org, etc) is appended to a name if it doesn't contain dots, and also a "www." can be prepended to it (thereby allowing you to type google in your browser and have it complete it to www.google.com. Some browsers can even be customized with details about this rewriting... -- Schnolle 16:48, 2004 Oct 24 (UTC)

---

Title says Uniform, first sentence says Universal....which is right? 41222-KenS

Uniform is correct. Check some of the external links... Schnolle 10:01, 24 Dec 2004 (UTC)

[edit] New RFC

What about RFC 3987? --ajvol 08:40, 22 Apr 2005 (UTC)

Irrelevant. RFC 3987 (IRI generic syntax) is essentially an extension to RFC 3986 (URI generic syntax), which supercedes the previous version, RFC 2396, which supercedes the RFCs that define URLs. As RFC 3305 (Aug 2002) explains, the term URL has effectively been obsolete for some time. The longevity of the term URL is attributable to a number of factors, not the least of which is horrible articles like this one. So if you're going to ask 'what about RFC ___?', you should probably ask 'how can we make this article better reflect the modern view of URL as being an informal term for a certain class of URIs, with respect to RFCs 2396, 3986, and 3305?' —mjb 01:37, 25 Apr 2005 (UTC)

[edit] Merging with URI

I think the bulk of content on this page should be merged with the page on URIs, leaving only parts really relevant to locators, as it is on the Uniform Resource Name. As specified in RFC 3986:

  An individual scheme does not have to be classified as being just one
  of "name" or "locator".  Instances of URIs from any given scheme may
  have the characteristics of names or locators or both, often
  depending on the persistence and care in the assignment of
  identifiers by the naming authority, rather than on any quality of
  the scheme.  Future specifications and related documentation should
  use the general term "URI" rather than the more restrictive terms
  "URL" and "URN" [RFC3305].

Hrvoje Šimić 07:00, 13 September 2005 (UTC)

That may be technically correct as far as the spec goes, but the term URL is much more popular, so I'd favor the current arrangement. --William Pietri 07:58, 7 October 2005 (UTC)

I agree that URL is a more popular term, but I don't think that should be the main criteria for Wikipedia organisation. Page on URL could explain the popular and the technical meaning, and refer to the page on URI for details, while containing information specific to locators. This approach is used many times on Wikipedia (e.g. Monkey/Ape). Besides, I don't think that current arrangement is anything to be satisfied about: articles overlap in scope, duplicate material, etc. Hrvoje Šimić 08:27, 11 October 2005 (UTC)

Sorry, but I'm still unpersuaded. I agree that some of the material here could move into URI, and that the article could use some cleanup. But I think there are two definitions of URL: what the very small number of people who read and follow the RFCs mean, and what the buik of internet-connected English-speakers (including most web programmers I know) mean. In addition to mentioning the formal URI/URN/URL distinction and formally defining the official URL, I think this article should continue to contain an explanation of URL that's friendly to the man on the street. -- William Pietri 02:59, 12 October 2005 (UTC)

Could you explain about the two definitions of "URL"? If I understood you correctly, the one definition is "popular URL" which should correspond to the "rfc URI", and the other one is "rfc URL". The "popular URL" part should cover the same topic as "rfc URI", but in a different, more practical language, like "type in the protocol name, colon, slash, slash, computer name, the file path and the file name". I think that approach is wrong. The Web may started like that, but it grew into so much more. And the models and definitions changed accordingly. And they were changed not by theorists or politicians, but by the same people who invented it in the first place. And they changed it not because they felt like it, but because they were forced to. The Web would be much more limited and confusing without the change. I wish I have been given this "RFC view" when I was learning about the Web, instead of the contradictory and misleading material I found. That being said, I don't mind covering history, the popular and "practical" aspects of the topic. In fact, I think it is essential for explaining why the RFCs are the way they are. But I'm all for bringing these two views together, instead of keeping them apart. -- Hrvoje Šimić 08:24, 12 October 2005 (UTC)

There is a difference between a URI and a URL according to other Wikipedia articles. A URL is a kind of URI, another kind of a URI is a URN (e.g. a Magnet link). A URL specifies a location, a URI does not always as the URN specifies data. --Computerjoe 17:47, 17 November 2005 (UTC)

I agree with William and Joe on both points. Technically, URLs have some features that make them different from URI in general. Intuitively, the use of the term URL is still much used even in technical contexts, even if URI should be sometimes used. However, my main reason for keeping the articles separated is to ease the reading and learning of these concepts. In this case at least, it is much easier to first learn about URLs and then discovering that these are particular cases of URI rather than the other way around. The fact that the article on URI starts with a section that explains the relationship between URI, URL, and URN seems to me a proof of this. I am not even so much convinced that the URL article should insist so much in comparing URLs with URIs from the beginning. Paolo Liberatore (Talk) 22:04, 2 December 2005 (UTC)

The proposal is to keep both articles. The merging refers to the content of the URL article that talks about URIs in general. The new URL article should contain information specific to the concept of URL, relation to URI, and the popular and historical usage of the term. Hrvoje Šimić 18:45, 6 December 2005 (UTC)

I agree that the article would be improved by being more specific on URLs. At some point, URLs had been very important in the specification of the Web, and the current "popular" use of URLs is mainly based on that specification. A possible solution could be to describe the (historical) specification, leaving the comparison with the current specification at the end. What I propose is something like:

1. intro (more or less as is, removing most of the second paragraph but adding a note saying that URLs are technically extinct)
2. origins (I assume that the basic idea was that of having a single string to identify files that can be retrived in different ways)
3. syntax (the hystorical one, without referring to URI)
4. the specific case of HTTP URLs
5. why URLs were replaced by URIs, and the current specification

Your last comment made me realize that perhaps there is a way of writing this article that satisfies all of us. The point I insist is that the reader should be able to read the URL article completely without having to read the URI article first. Paolo Liberatore (Talk) 19:16, 6 December 2005 (UTC)

Sorry I missed your earlier comment, Hrvoje. Paolo's proposed solution seems like a great approach to me, and firmly in keeping with NPOV. --William Pietri 15:31, 7 December 2005 (UTC)

[edit] Pronunciation

A Uniform Resource Locator, URL (spelled out as an acronym, not pronounced as 'earl')

Yuarell is the technically correct pronunciation, but in terms of actual usage it is pronounced as Earl by a lot of people, whether it's formally correct or not.

Out of curiosity, I checked with a number of pals who did web stuff early on, mainly at Hotwired. The they all agree on you-are-ell. -- William Pietri 02:36, 12 October 2005 (UTC)

Same in France, for all computer users. Either in French or in English, they prononce it as an initialism, not as an acronym (earl, ou [yrl] in French)

Technically, all pronounable acronyms are supposed to be pronounced... Thus, NATO is not pronounced n-a-t-o and URL should be pronounced "earl." I won't change the article until I get some input from other Wikipedians though... --Wulf 00:27, 29 April 2006 (UTC)

"Technically, all pronounable acronyms are supposed to be pronounced." That's ridiculous. --153.48.52.241 (talk) 16:45, 6 March 2008 (UTC)

According to The Internet for Dummies (10th edition), it's never pronounced as though it's a word. (Excerpt at Dummies.com.) B7T 18:08, 5 May 2006 (UTC)

You must define pronouncable. HTTP could be hatuhtuhpuh, or, UAE as ooay. VCR could be vacur. CD-cud, dvd-duved. need i go on?

LCD TV is lukd-tuv? Either way, even though it shouldn't be pronounced as a word, people do because it's easier to say that spelling it out. If it's able to be pronounced, people will pronounce it. As stated with NATO being Nay-Toe, PC being Pee-See, and RAID being Rayd it's all able to said without spelling it out. darthbob 19:03, 8 January 2008 (UTC)

[edit] Keep Both

Just summarise both debates and crosslink.

99% of internet users don't know what a URI is anyhow and a link from URL to URI wouldn't hurt.

[edit] HTTP cookie

I have submitted the article HTTP cookie for peer review (I am posting this notice here as this article is related). Comments are welcome here: Wikipedia:Peer review/HTTP cookie/archive1. Thanks. - Liberatore(T) 16:57, 14 January 2006 (UTC)

[edit] RFC 1738 is now far obsolete

I'm not a native english speaker, and not registered in the english version of WikiPedia. Bu I would like to tell you that the RFC 1738 is now far obsolete, and that the article should refere to RFC 3986 wich have the status of standard (STD 0066).

I may come in few week later to do the update if nobodies have done it... but I prefer native english speaker to do it.

[edit] URL and IP address

Shouldn't there be something about how a DNS server resolves a URL into an IP address? I started writing something but realised I didn't know enough about it, so someone else had better do that. DirkvdM 18:40, 5 March 2006 (UTC)

• I agree, at least a one-liner with hyperlinks to the wikipedia articles for 'DNS Server' and 'IP Address'. Something like

  A network lookup service, the Domain Name System (DNS),
  provides the ability to map domain names to a specific
  IP address.  For example, the URL www.wikipedia.org 
  maps to the IP address 207.142.131.248.

(which I stole with minor modification from the DNS article)

--Mcswell 19:30, 30 June 2006 (UTC)

• URLs don't necessarily have a host part, so they don't always need to do IP resolution. --66.241.66.190 (talk) 19:23, 27 November 2007 (UTC)

[edit] URL of this article

To quote the article: "For example, the URL of this page on Wikipedia is http://en.wikipedia.org/wiki/Uniform_Resource_Locator."

However, I came across this page by searching for "url", which directed me to another version of this page, which of course has a different URL! This could be confusing to some who arrived at that page instead, and noticed that the URL in the above sentence is not the same as the text in their browser's address bar. (If there is a way to use the Wikipedia markup language to always show the correct URL of a page within the text of a page, this would be a good place to use it.) B7T 18:36, 5 May 2006 (UTC)

At some point, Wikipedia may go on CD or even on paper, where using a URL that depends on the web page will not work. While the sentence "the URL of this page on Wikipedia" is formally correct (that is indeed the URL of that page in the Wikipedia web site) it may be somehow misleading if read on answer.com etc. I'd support choosing an enterely different URL as an example. - Liberatore(T) 17:54, 6 May 2006 (UTC)

[edit] mailto

I'm confused about the mailto: being a URL rather than a URN. This is because a URL tells you how to get there, which mailto: doesn't really do. After all, mailto:person@server.com will probably end up in a file like /user/person/mail/342345 on server.com. Furthermore, the mail actually gets sent to the sender's SMTP server before heading to server.com. It's like writing a letter to John Doe, and having the post office try and figure out where John Doe lives. So shouldn't mailto: be classified as a URN? If not, then why is it a URL? (P.S. sorry for the mailto auto-link, I don't know how to turn that off...) IMacWin95 22:18, 15 June 2006 (UTC)

A URN is a name for a thing, which should have a very long lifetime. A URL is a current locator, a much more transient concept. Thus, for example, "mail:John Doe, son of Jim Doe and Mary Roe, born 1972-02-27 in St. Elegius Hospital, Boston MA, USA, Boston birth certificate #123-456-78" could be a URN because it is a permanent reference, but "mailto:John@Doe.Com" has to be a URL because that account might be reused a dozen times in the next 100 years.

P.S. To stop the automatic treatment of almost any text in Wikipedia, wrap it in <nowiki>...</nowiki>. RossPatterson 01:20, 16 June 2006 (UTC)

[edit] Avoid self-references

avoid self-references to wikipedia —Preceding unsigned comment added by 71.123.46.27 (talk • contribs) 18 July 2006

[edit] Aug 2006 deletions and the future of this article

Etan Wexler removed a large amount of text from the article in mid-August. The changes weren't really discussed here, and now, a few weeks later, people are being tempted to start adding material that covers some of what was previously removed. Although I don't oppose Wexler's edit (most things that can be said about URLs are covered by the URI article), in Wikipedia we often have to acknowledge the priorities of contributors: someone came to this recently-trimmed article and felt that it was missing examples and details, so they attempted to add this info. They did a poor job of it, so I reverted, but this is not a battle I want to have to keep fighting. I hold it up as an example of how we can't rely on people to refer to linked articles like Uniform Resource Identifier; we either have to explain why they need to refer to that other article, or we need to address the topics of interest here, even if it means replicating or making repeated reference to material better covered elsewhere. Thoughts? —mjb 14:25, 6 September 2006 (UTC)

I think that in this article there are actually two concepts hidden under the same label:

1. URL as a popular synonym for URI;
2. URLs as locators, in contrast to identifiers and names.

These two meanings should be clearly stated in the introduction. The second meaning should be covered very briefly in the article, because this distinction is rarely needed in practice, as well as being marginal in theory. The introduction should strongly refer reader to article on URI for the complete coverage of the first meaning. Following sections would explain this in detail:

• Term URL in popular culture. Here we should give the brief, dumbed-down, practical definition of the URI (alias URL) to satisfy the superficial curiosity. Then, in more detail, we should explain why the term URI replaces it now.
• URLs as locators: a technical discussion.
• History of URL and how the change in terminology and semantics happened.

What is not needed are the schema listings and concrete syntaxes, as these are available on URI and URI scheme.

—Hrvoje Šimić 15:56, 6 September 2006 (UTC)

[edit] What was the purpose of the double-slash again?

Rather obviously, the slashes are not part of the protocol name -- otherwise they'd be on the other side of the colon. Thus, they are seperators of some kind for something which is in the hierarchy above the domain name, even above the TLD.

Are they merely historical artifacts? Have they ever actually seperated any values other than <null>? i.e. are there any circumstances, at least historically, why an URL would be any different than http:<null>/<null>/example.com? Or are they not actual seperators but rather an indicator of some sorts?

Considering other URI schemes, such as URNs, or different protocols (mailto, tel, etc) do not use initial slashes, this is a bit awkward for http and ftp protocols. — Ashmodai ^{(talk · contribs)} 00:14, 8 October 2006 (UTC)

Oopsie. The RFC has it all. In case anybody else was wondering:

Many URI schemes include a hierarchical element for a naming

authority so that governance of the name space defined by the

remainder of the URI is delegated to that authority (which may, in

turn, delegate it further). The generic syntax provides a common

means for distinguishing an authority based on a registered name or

server address, along with optional port and user information.

The authority component is preceded by a double slash ("//") and is

terminated by the next slash ("/"), question mark ("?"), or number

sign ("#") character, or by the end of the URI.

i.e. it's an indicator for the next segment to be the name of the authority for the rest of the URL. I guess http:/foo/bar.html would therefore be (theoretically) legal within the context of the server on which the content resides. In theory, anyway. I suppose the HTTP protocol forbids that use, as relative URLs omit the protocol prefix entirely. So I guess the FILE protocol has a leading double-slash followed by a slash (for the system root) to indicate that the authority is <null>, i.e. local, inherent or non-existant, or something. — Ashmodai ^{(talk · contribs)} 00:24, 8 October 2006 (UTC)

[edit] delimiters

Aren't there alternatives to the '?' and '&' in the query strings?

Also, do the delimitters around the username and password reduce the availability of those delimiters in the actual username/password. For example, can a password contain an '@' and/or ':'? —The preceding unsigned comment was added by Davidmaxwaterman (talk • contribs) 04:49, 9 May 2007 (UTC).

[edit] Is it okay?

Is it okay if we can create URL's? Plus, I don't know how to create them. I'm creating a homepage using Publisher 2003.--  PNiddy  Go!  0 00:14, 27 June 2007 (UTC)

Don't know about how to create them, (Not the place to ask about them) but wikipedia uses clean URLs. —Andrew Hampe ^Talk 17:03, 2 July 2007 (UTC)

[edit] 'clean URLs with web services'

Do we need this section? The services suggest don't seem to obey the ideas mentioned in the list above and I don't think we gain anything by mentioning them. Robin 14:18, 12 July 2007 (UTC)

I agree, I really don't think they're needed. SQL^{(Query Me!)} 10:02, 12 October 2007 (UTC)

OK, 'be bold' :) I've removed both the 'web services' section and following subsection. Robin 14:57, 16 October 2007 (UTC)

I like it :) Good work! SQL^{(Query Me!)} 02:33, 19 October 2007 (UTC)

I don't know what this section was, but I came here from a link (from another article) to http://en.wikipedia.org/wiki/Uniform_Resource_Locator#Clean_URLs ... which is a section that no longer exists. Can't find it in the history, though. Put it back if you can, I want to read it.

My edit is here in the history. I don't think it deserves reinstatement, but by all means argue against me :) Which page linked through to that section? Robin (talk) —Preceding comment was added at 10:09, 20 March 2008 (UTC)

OK, I found a reference in Rewrite engine and removed it. If there are any more then feel free to edit. Robin (talk) 11:55, 9 June 2008 (UTC)

[edit] Fair use rationale for Image:Address Bar - Wikipedia.png

Image:Address Bar - Wikipedia.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 20:30, 29 August 2007 (UTC)

Corrected. I replaced the rationale with a more bot-ready template. SQL^{(Query Me!)} 10:01, 12 October 2007 (UTC)