Relative path or url for html src and href attributes - html

Using a framework makes it easy to list full url's for my html src and href attributes, and I feel I'm being more thorough by listing a full url instead of a relative path. But is this faster? Am I incurring an extra DNS lookup? What is the best practice when the content is on the same server?
<img src='http://site.com/images/img1.png' />
vs
<img src='/images/img1.png' />
Codeigniter's image helper img() works like this from the users' guide:
echo img('images/picture.jpg');
// gives <img src="http://site.com/images/picture.jpg" />
and Codeigniter's anchor helper anchor() works like this from the users guide:
echo anchor('news/local/123','My News');
// gives <a href="http://example.com/index.php/news/local/123" >My News</a>


As far as DNS goes, it really doesn't matter if you have relative or absolute URL. Your browser ends up pre-pending the server URI onto the front anyway. Also, your network stack does the lookup for the first time, and caches the IP. Unless something goes wrong, there should only be the one lookup per page. YMMV of course, but that should be how this all works.


'Never' (alsmost never) use absolute paths.
It will bite you in the ass later.
For example when you switch / add another domain.
Go from your test to production server.
Basically the rule is internal URL's should be relative.


Oh you really don't want to use a full path. You'll have a lot of work ahead of you:
If you want to develop the site locally
You change / add domains (development, staging, etc)
You switch to using a CDN
You also will break your dev environment, since most modern ones will perform local directory lookups. Can't do that with a domain.
Also, in a dev environment you will be pulling from the production site, which will make modifying and adding images extremely tricky.
Most importantly, other developers working with your code will try to kill you. And that's bad for your health.


Portability would be the issue for me. I would choose the second option based on that alone.

Related

Should I prefer dot-slash links ("./foo/bar" over "/foo/bar") when writing root-relative links for both file: and http: URIs? [duplicate]

I would like to know the differences between these two types of URLs: relative URLs (for pictures, CSS files, JS files, etc.) and absolute URLs.
In addition, which one is better to use?

Should I use absolute or relative URLs?
If by absolute URLs you mean URLs including scheme (e.g. HTTP / HTTPS) and the hostname (e.g. yourdomain.example) don't ever do that (for local resources) because it will be terrible to maintain and debug.
Let's say you have used absolute URL everywhere in your code like <img src="http://yourdomain.example/images/example.png">. Now what will happen when you are going to:
switch to another scheme (e.g. HTTP -> HTTPS)
switch domain names (test.yourdomain.example -> yourdomain.example)
In the first example what will happen is that you will get warnings about unsafe content being requested on the page. Because all your URLs are hardcoded to use http(://yourdomain.example/images/example.png). And when running your pages over HTTPS the browser expects all resources to be loaded over HTTPS to prevent leaking of information.
In the second example when putting your site live from the test environment it would mean all resources are still pointing to your test domain instead of your live domain.
So to answer your question about whether to use absolute or relative URLs: always use relative URLs (for local resources).
What are the differences between the different URLs?
First lets have a look at the different types of URLs that we can use:
http://yourdomain.example/images/example.png
//yourdomain.example/images/example.png
/images/example.png
images/example.png
What resources do these URLs try to access on the server?
In the examples below I assume the website is running from the following location on the server /var/www/mywebsite.
http://yourdomain.example/images/example.png
The above (absolute) URL tries to access the resource /var/www/website/images/example.png. This type of URL is something you would always want to avoid for requesting resources from your own website for reason outlined above. However it does have its place. For example if you have a website http://yourdomain.example and you want to request a resource from an external domain over HTTPS you should use this. E.g. https://externalsite.example/path/to/image.png.
//yourdomain.example/images/example.png
This URL is relative based on the current scheme used and should almost always be used when including external resources (images, javascripts etc).
What this type of URL does is use the current scheme of the page it is on. This means that you are on the page http://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in http://yourdomain.example/images/example.png.
When you would have been on the page https://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in https://yourdomain.example/images/example.png.
This prevent loading resources over HTTPS when it is not needed and automatically makes sure the resource is requested over HTTPS when it is needed.
The above URL resolves in the same manner on the server side as the previous URL:
The above (absolute) URL tries to access the resource /var/www/website/images/example.png.
/images/example.png
For local resources this is the prefered way of referencing them. This is a relative URL based on the document root (/var/www/mywebsite) of your website. This means when you have <img src="/images/example.png"> it will always resolve to /var/www/mywebsite/images/example.png.
If at some point you decide to switch domain it will still work because it is relative.
images/example.png
This is also a relative URL although a bit different than the previous one. This URL is relative to the current path. What this means is that it will resolve to different paths depending on where you are in the site.
For example when you are on the page http://yourdomain.example and you use <img src="images/example.png"> it would resolve on the server to /var/www/mywebsite/images/example.png as expected, however when your are on the page http://yourdomain.example/some/path and you use the exact same image tag it suddenly will resolve to /var/www/mywebsite/some/path/images/example.png.
When to use what?
When requesting external resources you most likely want to use an URL relative to the scheme (unless you want to force a different scheme) and when dealing with local resources you want to use relative URLs based on the document root.
An example document:
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>
Some (kinda) duplicates
Safe way to write URLs that transfer across environments
what is the correct way to link image in website?

In general, it is considered best-practice to use relative URLs, so that your website will not be bound to the base URL of where it is currently deployed. For example, it will be able to work on localhost, as well as on your public domain, without modifications.

See this: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password#example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extension
An absolute URL includes the parts before the "path" part - in other words, it includes the scheme (the http in http://foo/bar/baz) and the hostname (the foo in http://foo/bar/baz) (and optionally port, userinfo and port).
Relative URLs start with a path.
Absolute URLs are, well, absolute: the location of the resource can be resolved looking only at the URL itself. A relative URL is in a sense incomplete: to resolve it, you need the scheme and hostname, and these are typically taken from the current context. For example, in a web page at
http://myhost/mypath/myresource1.html
you could put a link like so
click me
In the href attribute of the link, a relative URLs used, and if it is clicked, it has to be resolved in order to follow it. In this case, the current context is
http://myhost/mypath/myresource1.html
so the schema, hostname, and leading path of these are taken and prepended to pages/page1, yielding
http://myhost/mypath/pages/page1
If the link would have been:
click me
(note the / appearing at the start of the URL) then it would have been resolved as
http://myhost/pages/page1
because the leading / indicates the root of the host.
In a webapplication, I would advise to use relative URLs for all resources that belong to your app. That way, if you change the location of the pages, everything will continue to work. Any external resources (could be pages completely outside your application, but also static content that you deliver through a content delivery network) should always be pointed to using absolute URLs: if you don't there simply is no way to locate them, because they reside on a different server.

Assume we are creating a subsite whose files are in the folder http://site.ru/shop.
1. Absolute URL
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
2. Relative URL
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
Although relative URL look shorter than absolute one, but the absolute URLs are more preferable, since a link can be used unchanged on any page of site.
Intermediate cases
We have considered two extreme cases: "absolutely" absolute and "absolutely" relative URLs. But everything is relative in this world. This also applies to URLs. Every time you say about absolute URL, you should always specify relative to what.
3. Protocol-relative URL
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google recommends such URL. Now, however, it is generally considered that http:// and https:// are different sites.
4. Root-relative URL
I.e. relative to the root folder of the domain.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
It is a good choice if all pages are within the same domain. When you move your site to another domain, you don't have to do a mass replacements of the domain name in the URLs.
5. Base-relative URL (home-page-relative)
The tag <base> specifies the base URL, which is automatically added to all relative links and anchors. The base tag does not affect absolute links. As a base URL we'll specify the home page: <base href="http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
Now you can move your site not only to any domain, but in any subfolder. Just keep in mind that, although URLs look like relative, in fact they are absolute.
Especially pay attention to anchors. To navigate within the current page we have to write href="t-shirts/t-shirt-life-is-good/#comments" not href="#comments". The latter will throw on home page.
Conclusion
For internal links I use base-relative URLs (5). For external links and newsletters I use absolute URLs (1).

There are really three types that should be discussed explicitly. In practice though URLs have been abstracted to be handled at a lower level and I would go as far as to say that developers could go through their entire lives without writing a single URL by hand.
Absolute
Absolute URLs tie your code to the protocol and domain. This can be overcome with dynamic URLs.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
Absolute Pros:
Control - The subdomain and protocol can be controlled. People that enter through an obscure subdomain will be funneled into the proper subdomain. You can hop back and forth between secure and non-secure as appropriate.
Configurable - Developers love things to be absolute. You can design neat algorithms when using absolute URLs. URLs can be made configurable so that a URL can be updated site-wide with a single change in a single configuration file.
Clairvoyance - You can search for the people scraping your site or maybe pick up some extra external links.
Root Relative
Root Relative URLs tie your code to the base url. This can be overcome with dynamic URLs and/or base tags.
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Root Relative Pros:
Configurable - The base tag makes them relative to any root you choose making switching domains and implementing templates easy.
Relative
Relative URLs tie your code to the directory structure. There is no way to overcome this. Relative URLs are only useful in file systems for traversing directories or as a shortcut for a menial task.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
Relative Cons:
CONFUSING - How many dots is that? how many folders is that? Where is the file? Why isn't it working?
MAINTENANCE - If a file is accidentally moved resources quit loading, links send the user to the wrong pages, form data might be sent to the incorrect page. If a file NEEDS to be moved all the resources that are going to quit loading and all the links that are going to be incorrect need to be updated.
DOES NOT SCALE - When webpages become more complex and views start getting reused across multiple pages the relative links will be relative to the file that they were included into. If you have a navigation snippet of HTML that is going to be on every page then relative will be relative to a lot of different places. The first thing people realize when they start creating a template is that they need a way to manage the URLs.
COMPUTED - They are implemented by your browser (hopefully according to RFC). See chapter 5 in RFC3986.
OOPS! - Errors or typos can result in spider traps.
The Evolution of Routes
Developers have stopped writing URLs in the sense being discussed here. All requests are for a website's index file and contain a query string, aka a route. The route can be thought of as a mini URL that tells your application the content to be generated.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Routes Pros:
All the advantages of absolute urls.
Use of any character in URL.
More control (Good for SEO).
Ability to algorithmically generate URLs. This allows the URLs to be configurable. Altering the URL is a single change in a single file.
No need for 404 not founds. Fallback routes can display a site map or error page.
Convenient security of indirect access to application files. Guard statements can make sure that everybody is arriving through the proper channels.
Practicality in MVC approach.
My Take
Most people will make use of all three forms in their projects in some way or another. The key is to understand them and to choose the one best suited for the task.

I'm going to have to disagree with the majority here.
I think the relative URL scheme is "fine" when you want to quickly get something up and running and not think outside the box, particularly if your project is small with few developers (or just yourself).
However, once you start working on big, fatty systems where you switch domains and protocols all the time, I believe that a more elegant approach is in order.
When you compare absolute and relative URLs in essence, Absolute wins. Why? Because it won't ever break. Ever. An absolute URL is exactly what it says it is. The catch is when you have to MAINTAIN your absolute URLs.
The weak approach to absolute URL linking is actually hard coding the entire URL. Not a great idea, and probably the culprit of why people see them as dangerous/evil/annoying to maintain. A better approach is to write yourself an easy to use URL generator. These are easy to write, and can be incredibly powerful- automatically detecting your protocol, easy to config (literally set the url once for the whole app), etc, and it injects your domain all by itself. The nice thing about that: You go on coding using relative URLs, and at run time the application inserts your URLs as full absolutes on the fly. Awesome.
Seeing as how practically all modern sites use some sort of dynamic back-end, it's in the best interest of said site to do it that way. Absolute URLs do more than just make you certain of where they point to- they also can improve SEO performance.
I might add that the argument that absolute URLs is somehow going to change the load time of the page is a myth. If your domain weighs more than a few bytes and you're on a dialup modem in the 1980s, sure. But that's just not the case anymore. https://stackoverflow.com/ is 25 bytes, whereas the "topbar-sprite.png" file that they use for the nav area of the site weighs in at 9+ kb. That means that the additional URL data is .2% of the loaded data in comparison to the sprite file, and that file is not even considered a big performance hit.
That big, unoptimized, full-page background image is much more likely to slow your load times.
An interesting post about why relative URLs shouldn't be used is here:
Why relative URLs should be forbidden for web developers
An issue that can arise with relatives, for instance, is that sometimes server mappings (mind you on big, messed up projects) don't line up with file names and the developer may make an assumption about a relative URL that just isn't true. I just saw that today on a project that I'm on and it brought an entire page down.
Or perhaps a developer forgot to switch a pointer and all of a sudden google indexed your entire test environment. Whoops- duplicate content (bad for SEO!).
Absolutes can be dangerous, but when used properly and in a way that can't break your build they are proven to be more reliable. Look at the article above which gives a bunch of reasons why the Wordpress url generator is super awesome.
:)

If it is for use within your website, it's better practice to use relative URL, like this if you need to move the website to another domain name or just debug locally, you can.
Take a look at what's stackoverflow is doing (ctrl+U in firefox):
<a href="/users/recent/90691"> // Link to an internal element
In some cases they use absolute urls :
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
... but this is only it's a best practice to improve speed. In your case, it doesn't look like you're doing anything like that so I wouldn't worry about it.

In most instances relative URLs are the way to go, they are portable by nature, which means if you wanted to lift your site and put it someone where else it would work instantly, reducing possibly hours of debugging.
There is a pretty decent article on absolute vs relative URLs, check it out.

A URL that starts with the URL scheme and scheme specific part (http://, https://, ftp://, etc.) is an absolute URL.
Any other URL is a relative URL and needs a base URL the relative URL is resolved from (and thus depend on) that is the URL of the resource the reference is used in if not declared otherwise.
Take a look at RFC 2396 – Appendix C for examples of resolving relative URLs.

Let's say you have a site www.yourserver.example. In the root directory for web documents you have an images sub-directoy and in that you have myimage.jpg.
An absolute URL defines the exact location of the document, for example:
http://www.yourserver.example/images/myimage.jpg
A relative URL defines the location relative to the current directory, for example, given you are in the root web directory your image is in:
images/myimage.jpg
(relative to that root directory)
You should always use relative URLs where possible. If you move the site to www.anotherserver.com you would have to update all the absolute URLs that were pointing at www.yourserver.example, relative ones will just keep working as is.

For every system that support relative URI resolution, both relative and absolute URIs do serve the same goal: referencing. And they can be used interchangeably. So you could decide in each case differently. Technically, they provide the same referencing.
To be precise, with each relative URI there already is an absolute URI. And that's the base-URI that relative URI is resolved against. So a relative URI is actually a feature on top of absolute URIs.
And that's also why with relative URIs you can do more as with an absolute URI alone - this is especially important for static websites which otherwise couldn't be as flexible to maintain as compared to absolute URIs.
These positive effects of relative URI resolution can be exploited for dynamic web-application development as well. The inflexibility absolute URIs do introduce are also easier to cope up with, in a dynamic environment, so for some developers that are unsure about URI resolution and how to properly implement and manage it (not that it's always easy) do often opt into using absolute URIs in a dynamic part of a website as they can introduce other dynamic features (e.g. configuration variable containing the URI prefix) so to work around the inflexibility.
So what is the benefit then in using absolute URIs? Technically there ain't, but one I'd say: Relative URIs are more complex because they need to be resolved against the so called absolute base-URI. Even the resolution is strictly define since years, you might run over a client that has a mistake in URI resolution. As absolute URIs do not need any resolution, using absolute URIs have no risk to run into faulty client behaviour with relative URI resolution. So how high is that risk actually? Well, it's very rare. I only know about one Internet browser that had an issue with relative URI resolution. And that was not generally but only in a very (obscure) case.
Next to the HTTP client (browser) it's perhaps more complex for an author of hypertext documents or code as well. Here the absolute URI has the benefit that it is easier to test, as you can just enter it as-is into your browsers address bar. However, if it's not just your one-hour job, it's most often of more benefit to you to actually understand absolute and relative URI handling so that you can actually exploit the benefits of relative linking.

I would heartily recommend relative URLs for pointing bits of the same site to other bits of the same site.
Don't forget that a change to HTTPS - even if in the same site - is going to need an absolute URL.

Static files are not being served with gin's Grouping routes [duplicate]

I would like to know the differences between these two types of URLs: relative URLs (for pictures, CSS files, JS files, etc.) and absolute URLs.
In addition, which one is better to use?

Should I use absolute or relative URLs?
If by absolute URLs you mean URLs including scheme (e.g. HTTP / HTTPS) and the hostname (e.g. yourdomain.example) don't ever do that (for local resources) because it will be terrible to maintain and debug.
Let's say you have used absolute URL everywhere in your code like <img src="http://yourdomain.example/images/example.png">. Now what will happen when you are going to:
switch to another scheme (e.g. HTTP -> HTTPS)
switch domain names (test.yourdomain.example -> yourdomain.example)
In the first example what will happen is that you will get warnings about unsafe content being requested on the page. Because all your URLs are hardcoded to use http(://yourdomain.example/images/example.png). And when running your pages over HTTPS the browser expects all resources to be loaded over HTTPS to prevent leaking of information.
In the second example when putting your site live from the test environment it would mean all resources are still pointing to your test domain instead of your live domain.
So to answer your question about whether to use absolute or relative URLs: always use relative URLs (for local resources).
What are the differences between the different URLs?
First lets have a look at the different types of URLs that we can use:
http://yourdomain.example/images/example.png
//yourdomain.example/images/example.png
/images/example.png
images/example.png
What resources do these URLs try to access on the server?
In the examples below I assume the website is running from the following location on the server /var/www/mywebsite.
http://yourdomain.example/images/example.png
The above (absolute) URL tries to access the resource /var/www/website/images/example.png. This type of URL is something you would always want to avoid for requesting resources from your own website for reason outlined above. However it does have its place. For example if you have a website http://yourdomain.example and you want to request a resource from an external domain over HTTPS you should use this. E.g. https://externalsite.example/path/to/image.png.
//yourdomain.example/images/example.png
This URL is relative based on the current scheme used and should almost always be used when including external resources (images, javascripts etc).
What this type of URL does is use the current scheme of the page it is on. This means that you are on the page http://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in http://yourdomain.example/images/example.png.
When you would have been on the page https://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in https://yourdomain.example/images/example.png.
This prevent loading resources over HTTPS when it is not needed and automatically makes sure the resource is requested over HTTPS when it is needed.
The above URL resolves in the same manner on the server side as the previous URL:
The above (absolute) URL tries to access the resource /var/www/website/images/example.png.
/images/example.png
For local resources this is the prefered way of referencing them. This is a relative URL based on the document root (/var/www/mywebsite) of your website. This means when you have <img src="/images/example.png"> it will always resolve to /var/www/mywebsite/images/example.png.
If at some point you decide to switch domain it will still work because it is relative.
images/example.png
This is also a relative URL although a bit different than the previous one. This URL is relative to the current path. What this means is that it will resolve to different paths depending on where you are in the site.
For example when you are on the page http://yourdomain.example and you use <img src="images/example.png"> it would resolve on the server to /var/www/mywebsite/images/example.png as expected, however when your are on the page http://yourdomain.example/some/path and you use the exact same image tag it suddenly will resolve to /var/www/mywebsite/some/path/images/example.png.
When to use what?
When requesting external resources you most likely want to use an URL relative to the scheme (unless you want to force a different scheme) and when dealing with local resources you want to use relative URLs based on the document root.
An example document:
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>
Some (kinda) duplicates
Safe way to write URLs that transfer across environments
what is the correct way to link image in website?

In general, it is considered best-practice to use relative URLs, so that your website will not be bound to the base URL of where it is currently deployed. For example, it will be able to work on localhost, as well as on your public domain, without modifications.

See this: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password#example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extension
An absolute URL includes the parts before the "path" part - in other words, it includes the scheme (the http in http://foo/bar/baz) and the hostname (the foo in http://foo/bar/baz) (and optionally port, userinfo and port).
Relative URLs start with a path.
Absolute URLs are, well, absolute: the location of the resource can be resolved looking only at the URL itself. A relative URL is in a sense incomplete: to resolve it, you need the scheme and hostname, and these are typically taken from the current context. For example, in a web page at
http://myhost/mypath/myresource1.html
you could put a link like so
click me
In the href attribute of the link, a relative URLs used, and if it is clicked, it has to be resolved in order to follow it. In this case, the current context is
http://myhost/mypath/myresource1.html
so the schema, hostname, and leading path of these are taken and prepended to pages/page1, yielding
http://myhost/mypath/pages/page1
If the link would have been:
click me
(note the / appearing at the start of the URL) then it would have been resolved as
http://myhost/pages/page1
because the leading / indicates the root of the host.
In a webapplication, I would advise to use relative URLs for all resources that belong to your app. That way, if you change the location of the pages, everything will continue to work. Any external resources (could be pages completely outside your application, but also static content that you deliver through a content delivery network) should always be pointed to using absolute URLs: if you don't there simply is no way to locate them, because they reside on a different server.

Assume we are creating a subsite whose files are in the folder http://site.ru/shop.
1. Absolute URL
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
2. Relative URL
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
Although relative URL look shorter than absolute one, but the absolute URLs are more preferable, since a link can be used unchanged on any page of site.
Intermediate cases
We have considered two extreme cases: "absolutely" absolute and "absolutely" relative URLs. But everything is relative in this world. This also applies to URLs. Every time you say about absolute URL, you should always specify relative to what.
3. Protocol-relative URL
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google recommends such URL. Now, however, it is generally considered that http:// and https:// are different sites.
4. Root-relative URL
I.e. relative to the root folder of the domain.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
It is a good choice if all pages are within the same domain. When you move your site to another domain, you don't have to do a mass replacements of the domain name in the URLs.
5. Base-relative URL (home-page-relative)
The tag <base> specifies the base URL, which is automatically added to all relative links and anchors. The base tag does not affect absolute links. As a base URL we'll specify the home page: <base href="http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
Now you can move your site not only to any domain, but in any subfolder. Just keep in mind that, although URLs look like relative, in fact they are absolute.
Especially pay attention to anchors. To navigate within the current page we have to write href="t-shirts/t-shirt-life-is-good/#comments" not href="#comments". The latter will throw on home page.
Conclusion
For internal links I use base-relative URLs (5). For external links and newsletters I use absolute URLs (1).

There are really three types that should be discussed explicitly. In practice though URLs have been abstracted to be handled at a lower level and I would go as far as to say that developers could go through their entire lives without writing a single URL by hand.
Absolute
Absolute URLs tie your code to the protocol and domain. This can be overcome with dynamic URLs.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
Absolute Pros:
Control - The subdomain and protocol can be controlled. People that enter through an obscure subdomain will be funneled into the proper subdomain. You can hop back and forth between secure and non-secure as appropriate.
Configurable - Developers love things to be absolute. You can design neat algorithms when using absolute URLs. URLs can be made configurable so that a URL can be updated site-wide with a single change in a single configuration file.
Clairvoyance - You can search for the people scraping your site or maybe pick up some extra external links.
Root Relative
Root Relative URLs tie your code to the base url. This can be overcome with dynamic URLs and/or base tags.
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Root Relative Pros:
Configurable - The base tag makes them relative to any root you choose making switching domains and implementing templates easy.
Relative
Relative URLs tie your code to the directory structure. There is no way to overcome this. Relative URLs are only useful in file systems for traversing directories or as a shortcut for a menial task.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
Relative Cons:
CONFUSING - How many dots is that? how many folders is that? Where is the file? Why isn't it working?
MAINTENANCE - If a file is accidentally moved resources quit loading, links send the user to the wrong pages, form data might be sent to the incorrect page. If a file NEEDS to be moved all the resources that are going to quit loading and all the links that are going to be incorrect need to be updated.
DOES NOT SCALE - When webpages become more complex and views start getting reused across multiple pages the relative links will be relative to the file that they were included into. If you have a navigation snippet of HTML that is going to be on every page then relative will be relative to a lot of different places. The first thing people realize when they start creating a template is that they need a way to manage the URLs.
COMPUTED - They are implemented by your browser (hopefully according to RFC). See chapter 5 in RFC3986.
OOPS! - Errors or typos can result in spider traps.
The Evolution of Routes
Developers have stopped writing URLs in the sense being discussed here. All requests are for a website's index file and contain a query string, aka a route. The route can be thought of as a mini URL that tells your application the content to be generated.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Routes Pros:
All the advantages of absolute urls.
Use of any character in URL.
More control (Good for SEO).
Ability to algorithmically generate URLs. This allows the URLs to be configurable. Altering the URL is a single change in a single file.
No need for 404 not founds. Fallback routes can display a site map or error page.
Convenient security of indirect access to application files. Guard statements can make sure that everybody is arriving through the proper channels.
Practicality in MVC approach.
My Take
Most people will make use of all three forms in their projects in some way or another. The key is to understand them and to choose the one best suited for the task.

I'm going to have to disagree with the majority here.
I think the relative URL scheme is "fine" when you want to quickly get something up and running and not think outside the box, particularly if your project is small with few developers (or just yourself).
However, once you start working on big, fatty systems where you switch domains and protocols all the time, I believe that a more elegant approach is in order.
When you compare absolute and relative URLs in essence, Absolute wins. Why? Because it won't ever break. Ever. An absolute URL is exactly what it says it is. The catch is when you have to MAINTAIN your absolute URLs.
The weak approach to absolute URL linking is actually hard coding the entire URL. Not a great idea, and probably the culprit of why people see them as dangerous/evil/annoying to maintain. A better approach is to write yourself an easy to use URL generator. These are easy to write, and can be incredibly powerful- automatically detecting your protocol, easy to config (literally set the url once for the whole app), etc, and it injects your domain all by itself. The nice thing about that: You go on coding using relative URLs, and at run time the application inserts your URLs as full absolutes on the fly. Awesome.
Seeing as how practically all modern sites use some sort of dynamic back-end, it's in the best interest of said site to do it that way. Absolute URLs do more than just make you certain of where they point to- they also can improve SEO performance.
I might add that the argument that absolute URLs is somehow going to change the load time of the page is a myth. If your domain weighs more than a few bytes and you're on a dialup modem in the 1980s, sure. But that's just not the case anymore. https://stackoverflow.com/ is 25 bytes, whereas the "topbar-sprite.png" file that they use for the nav area of the site weighs in at 9+ kb. That means that the additional URL data is .2% of the loaded data in comparison to the sprite file, and that file is not even considered a big performance hit.
That big, unoptimized, full-page background image is much more likely to slow your load times.
An interesting post about why relative URLs shouldn't be used is here:
Why relative URLs should be forbidden for web developers
An issue that can arise with relatives, for instance, is that sometimes server mappings (mind you on big, messed up projects) don't line up with file names and the developer may make an assumption about a relative URL that just isn't true. I just saw that today on a project that I'm on and it brought an entire page down.
Or perhaps a developer forgot to switch a pointer and all of a sudden google indexed your entire test environment. Whoops- duplicate content (bad for SEO!).
Absolutes can be dangerous, but when used properly and in a way that can't break your build they are proven to be more reliable. Look at the article above which gives a bunch of reasons why the Wordpress url generator is super awesome.
:)

If it is for use within your website, it's better practice to use relative URL, like this if you need to move the website to another domain name or just debug locally, you can.
Take a look at what's stackoverflow is doing (ctrl+U in firefox):
<a href="/users/recent/90691"> // Link to an internal element
In some cases they use absolute urls :
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
... but this is only it's a best practice to improve speed. In your case, it doesn't look like you're doing anything like that so I wouldn't worry about it.

In most instances relative URLs are the way to go, they are portable by nature, which means if you wanted to lift your site and put it someone where else it would work instantly, reducing possibly hours of debugging.
There is a pretty decent article on absolute vs relative URLs, check it out.

A URL that starts with the URL scheme and scheme specific part (http://, https://, ftp://, etc.) is an absolute URL.
Any other URL is a relative URL and needs a base URL the relative URL is resolved from (and thus depend on) that is the URL of the resource the reference is used in if not declared otherwise.
Take a look at RFC 2396 – Appendix C for examples of resolving relative URLs.

Let's say you have a site www.yourserver.example. In the root directory for web documents you have an images sub-directoy and in that you have myimage.jpg.
An absolute URL defines the exact location of the document, for example:
http://www.yourserver.example/images/myimage.jpg
A relative URL defines the location relative to the current directory, for example, given you are in the root web directory your image is in:
images/myimage.jpg
(relative to that root directory)
You should always use relative URLs where possible. If you move the site to www.anotherserver.com you would have to update all the absolute URLs that were pointing at www.yourserver.example, relative ones will just keep working as is.

For every system that support relative URI resolution, both relative and absolute URIs do serve the same goal: referencing. And they can be used interchangeably. So you could decide in each case differently. Technically, they provide the same referencing.
To be precise, with each relative URI there already is an absolute URI. And that's the base-URI that relative URI is resolved against. So a relative URI is actually a feature on top of absolute URIs.
And that's also why with relative URIs you can do more as with an absolute URI alone - this is especially important for static websites which otherwise couldn't be as flexible to maintain as compared to absolute URIs.
These positive effects of relative URI resolution can be exploited for dynamic web-application development as well. The inflexibility absolute URIs do introduce are also easier to cope up with, in a dynamic environment, so for some developers that are unsure about URI resolution and how to properly implement and manage it (not that it's always easy) do often opt into using absolute URIs in a dynamic part of a website as they can introduce other dynamic features (e.g. configuration variable containing the URI prefix) so to work around the inflexibility.
So what is the benefit then in using absolute URIs? Technically there ain't, but one I'd say: Relative URIs are more complex because they need to be resolved against the so called absolute base-URI. Even the resolution is strictly define since years, you might run over a client that has a mistake in URI resolution. As absolute URIs do not need any resolution, using absolute URIs have no risk to run into faulty client behaviour with relative URI resolution. So how high is that risk actually? Well, it's very rare. I only know about one Internet browser that had an issue with relative URI resolution. And that was not generally but only in a very (obscure) case.
Next to the HTTP client (browser) it's perhaps more complex for an author of hypertext documents or code as well. Here the absolute URI has the benefit that it is easier to test, as you can just enter it as-is into your browsers address bar. However, if it's not just your one-hour job, it's most often of more benefit to you to actually understand absolute and relative URI handling so that you can actually exploit the benefits of relative linking.

I would heartily recommend relative URLs for pointing bits of the same site to other bits of the same site.
Don't forget that a change to HTTPS - even if in the same site - is going to need an absolute URL.

Using a tilde in a url after a forward slash

I've come across a background image reference of this form in some HTML code I'm changing.
<a style="background: url('/~/media/Images/Shared/Logos/logo.png')" href="/">Home</a>
I'm not in a position to ask the original author, and I don't understand how the tilde is being evaluated here.
If the url string started "url('~/media/.....'" I understand would be the root of the media user (so you'd better be sure you create that user on all your deployment servers) but the / in front of the tilde has me confused.
All the searches I've done just bring back the home directory explanation, but it doesn't appear to be that.
[edit] This is part of a live site, the logo shows up correctly, I just don't know why.
[edit 2] The site is built using ASP.NET.
[edit 3] The above is a cleaned version of the url from a view/source on the site, not the ASP code.
[edit 4] For those that might be curious, here's the actual working url. I work for the same company, but a different division, and I'm building an internal support tool in Java EE which is borrowing some of the styling. I saw the "/~/...." and couldn't think of a good reason why it would work.
http://business.hibu.co.uk/~/media/Images/Shared/Logos/logo.png

In ASP.NET, a tilde represents the root of the application (not necessarily the root of the website). But it's only usable in certain circumstances (server controls, controls that are data-bound, or sometimes tags in the head section like script or link).
I wouldn't think an a tag in the regular body would handle it, and I don't think ASP.NET allows the tilde to go anywhere except the beginning of the string anyway.
So I'm guessing you simply actually have a physical directory named ~. In Windows, I don't think the tilde has any special meaning, so it's not the user's home directory or anything like that - just a funky name for a regular directory.
EDIT
After reading your comment that this is the way it's rendered in the browser, and it's working, I'm almost positive that there's a real directory called ~ on your web server. Either that or some kind of URL rewriting going on, which you'd need to see the web.config or IIS settings to see that.

That's likely from their local machine, meaning their home directory. It can never resolve properly from a remote server if the asset path was copied from their development machine.
Otherwise it's a path relative to the home directory on their server.

Absolute vs relative URLs

I would like to know the differences between these two types of URLs: relative URLs (for pictures, CSS files, JS files, etc.) and absolute URLs.
In addition, which one is better to use?

Should I use absolute or relative URLs?
If by absolute URLs you mean URLs including scheme (e.g. HTTP / HTTPS) and the hostname (e.g. yourdomain.example) don't ever do that (for local resources) because it will be terrible to maintain and debug.
Let's say you have used absolute URL everywhere in your code like <img src="http://yourdomain.example/images/example.png">. Now what will happen when you are going to:
switch to another scheme (e.g. HTTP -> HTTPS)
switch domain names (test.yourdomain.example -> yourdomain.example)
In the first example what will happen is that you will get warnings about unsafe content being requested on the page. Because all your URLs are hardcoded to use http(://yourdomain.example/images/example.png). And when running your pages over HTTPS the browser expects all resources to be loaded over HTTPS to prevent leaking of information.
In the second example when putting your site live from the test environment it would mean all resources are still pointing to your test domain instead of your live domain.
So to answer your question about whether to use absolute or relative URLs: always use relative URLs (for local resources).
What are the differences between the different URLs?
First lets have a look at the different types of URLs that we can use:
http://yourdomain.example/images/example.png
//yourdomain.example/images/example.png
/images/example.png
images/example.png
What resources do these URLs try to access on the server?
In the examples below I assume the website is running from the following location on the server /var/www/mywebsite.
http://yourdomain.example/images/example.png
The above (absolute) URL tries to access the resource /var/www/website/images/example.png. This type of URL is something you would always want to avoid for requesting resources from your own website for reason outlined above. However it does have its place. For example if you have a website http://yourdomain.example and you want to request a resource from an external domain over HTTPS you should use this. E.g. https://externalsite.example/path/to/image.png.
//yourdomain.example/images/example.png
This URL is relative based on the current scheme used and should almost always be used when including external resources (images, javascripts etc).
What this type of URL does is use the current scheme of the page it is on. This means that you are on the page http://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in http://yourdomain.example/images/example.png.
When you would have been on the page https://yourdomain.example and on that page is an image tag <img src="//yourdomain.example/images/example.png"> the URL of the image would resolve in https://yourdomain.example/images/example.png.
This prevent loading resources over HTTPS when it is not needed and automatically makes sure the resource is requested over HTTPS when it is needed.
The above URL resolves in the same manner on the server side as the previous URL:
The above (absolute) URL tries to access the resource /var/www/website/images/example.png.
/images/example.png
For local resources this is the prefered way of referencing them. This is a relative URL based on the document root (/var/www/mywebsite) of your website. This means when you have <img src="/images/example.png"> it will always resolve to /var/www/mywebsite/images/example.png.
If at some point you decide to switch domain it will still work because it is relative.
images/example.png
This is also a relative URL although a bit different than the previous one. This URL is relative to the current path. What this means is that it will resolve to different paths depending on where you are in the site.
For example when you are on the page http://yourdomain.example and you use <img src="images/example.png"> it would resolve on the server to /var/www/mywebsite/images/example.png as expected, however when your are on the page http://yourdomain.example/some/path and you use the exact same image tag it suddenly will resolve to /var/www/mywebsite/some/path/images/example.png.
When to use what?
When requesting external resources you most likely want to use an URL relative to the scheme (unless you want to force a different scheme) and when dealing with local resources you want to use relative URLs based on the document root.
An example document:
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>
Some (kinda) duplicates
Safe way to write URLs that transfer across environments
what is the correct way to link image in website?

In general, it is considered best-practice to use relative URLs, so that your website will not be bound to the base URL of where it is currently deployed. For example, it will be able to work on localhost, as well as on your public domain, without modifications.

See this: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
foo://username:password#example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ / \________________/\_________/ \__/ \___/ \_/ \_________/ \_________/ \__/
| | | | | | | | |
| userinfo hostname port | | parameter query fragment
| \_______________________________/ \_____________|____|____________/
scheme | | | |
| authority |path|
| | |
| path interpretable as filename
| ___________|____________ |
/ \ / \ |
urn:example:animal:ferret:nose interpretable as extension
An absolute URL includes the parts before the "path" part - in other words, it includes the scheme (the http in http://foo/bar/baz) and the hostname (the foo in http://foo/bar/baz) (and optionally port, userinfo and port).
Relative URLs start with a path.
Absolute URLs are, well, absolute: the location of the resource can be resolved looking only at the URL itself. A relative URL is in a sense incomplete: to resolve it, you need the scheme and hostname, and these are typically taken from the current context. For example, in a web page at
http://myhost/mypath/myresource1.html
you could put a link like so
click me
In the href attribute of the link, a relative URLs used, and if it is clicked, it has to be resolved in order to follow it. In this case, the current context is
http://myhost/mypath/myresource1.html
so the schema, hostname, and leading path of these are taken and prepended to pages/page1, yielding
http://myhost/mypath/pages/page1
If the link would have been:
click me
(note the / appearing at the start of the URL) then it would have been resolved as
http://myhost/pages/page1
because the leading / indicates the root of the host.
In a webapplication, I would advise to use relative URLs for all resources that belong to your app. That way, if you change the location of the pages, everything will continue to work. Any external resources (could be pages completely outside your application, but also static content that you deliver through a content delivery network) should always be pointed to using absolute URLs: if you don't there simply is no way to locate them, because they reside on a different server.

Assume we are creating a subsite whose files are in the folder http://site.ru/shop.
1. Absolute URL
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
2. Relative URL
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
Although relative URL look shorter than absolute one, but the absolute URLs are more preferable, since a link can be used unchanged on any page of site.
Intermediate cases
We have considered two extreme cases: "absolutely" absolute and "absolutely" relative URLs. But everything is relative in this world. This also applies to URLs. Every time you say about absolute URL, you should always specify relative to what.
3. Protocol-relative URL
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google recommends such URL. Now, however, it is generally considered that http:// and https:// are different sites.
4. Root-relative URL
I.e. relative to the root folder of the domain.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
It is a good choice if all pages are within the same domain. When you move your site to another domain, you don't have to do a mass replacements of the domain name in the URLs.
5. Base-relative URL (home-page-relative)
The tag <base> specifies the base URL, which is automatically added to all relative links and anchors. The base tag does not affect absolute links. As a base URL we'll specify the home page: <base href="http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
Now you can move your site not only to any domain, but in any subfolder. Just keep in mind that, although URLs look like relative, in fact they are absolute.
Especially pay attention to anchors. To navigate within the current page we have to write href="t-shirts/t-shirt-life-is-good/#comments" not href="#comments". The latter will throw on home page.
Conclusion
For internal links I use base-relative URLs (5). For external links and newsletters I use absolute URLs (1).

There are really three types that should be discussed explicitly. In practice though URLs have been abstracted to be handled at a lower level and I would go as far as to say that developers could go through their entire lives without writing a single URL by hand.
Absolute
Absolute URLs tie your code to the protocol and domain. This can be overcome with dynamic URLs.
<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>
Absolute Pros:
Control - The subdomain and protocol can be controlled. People that enter through an obscure subdomain will be funneled into the proper subdomain. You can hop back and forth between secure and non-secure as appropriate.
Configurable - Developers love things to be absolute. You can design neat algorithms when using absolute URLs. URLs can be made configurable so that a URL can be updated site-wide with a single change in a single configuration file.
Clairvoyance - You can search for the people scraping your site or maybe pick up some extra external links.
Root Relative
Root Relative URLs tie your code to the base url. This can be overcome with dynamic URLs and/or base tags.
<a href=“/index.php?q=”>.example.com/index.php?q=</a>
Root Relative Pros:
Configurable - The base tag makes them relative to any root you choose making switching domains and implementing templates easy.
Relative
Relative URLs tie your code to the directory structure. There is no way to overcome this. Relative URLs are only useful in file systems for traversing directories or as a shortcut for a menial task.
<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />
Relative Cons:
CONFUSING - How many dots is that? how many folders is that? Where is the file? Why isn't it working?
MAINTENANCE - If a file is accidentally moved resources quit loading, links send the user to the wrong pages, form data might be sent to the incorrect page. If a file NEEDS to be moved all the resources that are going to quit loading and all the links that are going to be incorrect need to be updated.
DOES NOT SCALE - When webpages become more complex and views start getting reused across multiple pages the relative links will be relative to the file that they were included into. If you have a navigation snippet of HTML that is going to be on every page then relative will be relative to a lot of different places. The first thing people realize when they start creating a template is that they need a way to manage the URLs.
COMPUTED - They are implemented by your browser (hopefully according to RFC). See chapter 5 in RFC3986.
OOPS! - Errors or typos can result in spider traps.
The Evolution of Routes
Developers have stopped writing URLs in the sense being discussed here. All requests are for a website's index file and contain a query string, aka a route. The route can be thought of as a mini URL that tells your application the content to be generated.
<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
http://dev.example.com/index.php/my:whacky:url
</a>
Routes Pros:
All the advantages of absolute urls.
Use of any character in URL.
More control (Good for SEO).
Ability to algorithmically generate URLs. This allows the URLs to be configurable. Altering the URL is a single change in a single file.
No need for 404 not founds. Fallback routes can display a site map or error page.
Convenient security of indirect access to application files. Guard statements can make sure that everybody is arriving through the proper channels.
Practicality in MVC approach.
My Take
Most people will make use of all three forms in their projects in some way or another. The key is to understand them and to choose the one best suited for the task.

I'm going to have to disagree with the majority here.
I think the relative URL scheme is "fine" when you want to quickly get something up and running and not think outside the box, particularly if your project is small with few developers (or just yourself).
However, once you start working on big, fatty systems where you switch domains and protocols all the time, I believe that a more elegant approach is in order.
When you compare absolute and relative URLs in essence, Absolute wins. Why? Because it won't ever break. Ever. An absolute URL is exactly what it says it is. The catch is when you have to MAINTAIN your absolute URLs.
The weak approach to absolute URL linking is actually hard coding the entire URL. Not a great idea, and probably the culprit of why people see them as dangerous/evil/annoying to maintain. A better approach is to write yourself an easy to use URL generator. These are easy to write, and can be incredibly powerful- automatically detecting your protocol, easy to config (literally set the url once for the whole app), etc, and it injects your domain all by itself. The nice thing about that: You go on coding using relative URLs, and at run time the application inserts your URLs as full absolutes on the fly. Awesome.
Seeing as how practically all modern sites use some sort of dynamic back-end, it's in the best interest of said site to do it that way. Absolute URLs do more than just make you certain of where they point to- they also can improve SEO performance.
I might add that the argument that absolute URLs is somehow going to change the load time of the page is a myth. If your domain weighs more than a few bytes and you're on a dialup modem in the 1980s, sure. But that's just not the case anymore. https://stackoverflow.com/ is 25 bytes, whereas the "topbar-sprite.png" file that they use for the nav area of the site weighs in at 9+ kb. That means that the additional URL data is .2% of the loaded data in comparison to the sprite file, and that file is not even considered a big performance hit.
That big, unoptimized, full-page background image is much more likely to slow your load times.
An interesting post about why relative URLs shouldn't be used is here:
Why relative URLs should be forbidden for web developers
An issue that can arise with relatives, for instance, is that sometimes server mappings (mind you on big, messed up projects) don't line up with file names and the developer may make an assumption about a relative URL that just isn't true. I just saw that today on a project that I'm on and it brought an entire page down.
Or perhaps a developer forgot to switch a pointer and all of a sudden google indexed your entire test environment. Whoops- duplicate content (bad for SEO!).
Absolutes can be dangerous, but when used properly and in a way that can't break your build they are proven to be more reliable. Look at the article above which gives a bunch of reasons why the Wordpress url generator is super awesome.
:)

If it is for use within your website, it's better practice to use relative URL, like this if you need to move the website to another domain name or just debug locally, you can.
Take a look at what's stackoverflow is doing (ctrl+U in firefox):
<a href="/users/recent/90691"> // Link to an internal element
In some cases they use absolute urls :
<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">
... but this is only it's a best practice to improve speed. In your case, it doesn't look like you're doing anything like that so I wouldn't worry about it.

In most instances relative URLs are the way to go, they are portable by nature, which means if you wanted to lift your site and put it someone where else it would work instantly, reducing possibly hours of debugging.
There is a pretty decent article on absolute vs relative URLs, check it out.

A URL that starts with the URL scheme and scheme specific part (http://, https://, ftp://, etc.) is an absolute URL.
Any other URL is a relative URL and needs a base URL the relative URL is resolved from (and thus depend on) that is the URL of the resource the reference is used in if not declared otherwise.
Take a look at RFC 2396 – Appendix C for examples of resolving relative URLs.

Let's say you have a site www.yourserver.example. In the root directory for web documents you have an images sub-directoy and in that you have myimage.jpg.
An absolute URL defines the exact location of the document, for example:
http://www.yourserver.example/images/myimage.jpg
A relative URL defines the location relative to the current directory, for example, given you are in the root web directory your image is in:
images/myimage.jpg
(relative to that root directory)
You should always use relative URLs where possible. If you move the site to www.anotherserver.com you would have to update all the absolute URLs that were pointing at www.yourserver.example, relative ones will just keep working as is.

For every system that support relative URI resolution, both relative and absolute URIs do serve the same goal: referencing. And they can be used interchangeably. So you could decide in each case differently. Technically, they provide the same referencing.
To be precise, with each relative URI there already is an absolute URI. And that's the base-URI that relative URI is resolved against. So a relative URI is actually a feature on top of absolute URIs.
And that's also why with relative URIs you can do more as with an absolute URI alone - this is especially important for static websites which otherwise couldn't be as flexible to maintain as compared to absolute URIs.
These positive effects of relative URI resolution can be exploited for dynamic web-application development as well. The inflexibility absolute URIs do introduce are also easier to cope up with, in a dynamic environment, so for some developers that are unsure about URI resolution and how to properly implement and manage it (not that it's always easy) do often opt into using absolute URIs in a dynamic part of a website as they can introduce other dynamic features (e.g. configuration variable containing the URI prefix) so to work around the inflexibility.
So what is the benefit then in using absolute URIs? Technically there ain't, but one I'd say: Relative URIs are more complex because they need to be resolved against the so called absolute base-URI. Even the resolution is strictly define since years, you might run over a client that has a mistake in URI resolution. As absolute URIs do not need any resolution, using absolute URIs have no risk to run into faulty client behaviour with relative URI resolution. So how high is that risk actually? Well, it's very rare. I only know about one Internet browser that had an issue with relative URI resolution. And that was not generally but only in a very (obscure) case.
Next to the HTTP client (browser) it's perhaps more complex for an author of hypertext documents or code as well. Here the absolute URI has the benefit that it is easier to test, as you can just enter it as-is into your browsers address bar. However, if it's not just your one-hour job, it's most often of more benefit to you to actually understand absolute and relative URI handling so that you can actually exploit the benefits of relative linking.

I would heartily recommend relative URLs for pointing bits of the same site to other bits of the same site.
Don't forget that a change to HTTPS - even if in the same site - is going to need an absolute URL.

is there a difference between absolute and relative paths when pointing to certain files on your html?

our office just got this new guy with lots of experience and kept insisting that we stop using absolute paths like: http://somesite.com/subdir1/images/filename.ext when pointing to a path of our image when it resides next to the file that calls it say we could have just used: ./subdir1/images/filename.ext
but the reason why we used absolute paths before was to prevent deadlinks when we put another page in another directory, instead of explicitly typing "../../" OR "./" recursively...
so is there really a difference when using them?
he said that each absolute urls is a separate request to the server.. but i've been using this method ever since and i can safely assure an expected fast response time, can anyone enlighten me?

Everything is a separate http request to the server. Relative or absolute it does not matter.
Of course, if the absolute url points to the same website but on a different host, then this may speed up things because it breaks the 2 concurrent http requests limit. e.g your site is at www.example.com and you serve all your images from static.example.com.
Another way to prevent the broken links issue you mention is by virtual URLs: /images/foo.png

Using relative paths make it possible for you to move your entire webapplication to another domain and/or folder without fixing every path.

Relative paths make for smaller HTML, resulting in less bandwidth consumption.
Relative paths are context friendly, meaning both "site.com" and "www.site.com" will work equally well, without the need for redirects from "site.com" to "www.site.com".

Absolute paths would be root absolute and versatile enough that you can later on move the file to another directory and the links would still work. And if you ever change the domain name, no problem, links still work.
/foo/monkey-wrench.song
Relative paths would be relative to the page you're on, and breaks if you ever move the file outside of its current directory.
../foo/everlong.song
Slapping on the domain part would make it an absolute URL.
http://example.com/foo/this-is-a-call.song
Which is good if you have a scraper come along and then they would be able to link back to your own site so that when you check the referrer logs, you know who to go about sending that take down notice to.
Difference between the two would be how much more busy work you want to create for yourself later on.

I prefer to parse Request.RawURL manually to avoid collisions with urls

There might be a bit of a cargo-cult thing going on there.
Where I work, we were told by the server techs that absolute URLs did cause delays, because there was load-balancing involved. An absolute URL would go back to the switch and be relayed to one of four servers, whereas a local one wouldn't.
So it might have been true at his old work place. Whether it's true at your workplace is for you to find out.
But if he can't explain why he's saying it, it's a folk-belief until proven otherwise.