What really happens when you navigate to a URL

As a software developer, you certainly have a high-level picture of how web apps work and what kinds of technologies are involved: the browser, HTTP, HTML, web server, request handlers, and so on.
In this article, we will take a deeper look at the sequence of events that take place when you visit a URL.

1. You enter a URL into the browser

It all starts here:

2. The browser looks up the IP address for the domain name

 
The first step in the navigation is to figure out the IP address for the visited domain. The DNS lookup proceeds as follows:

• Browser cache – The browser caches DNS records for some time. Interestingly, the OS does not tell the browser the time-to-live for each DNS record, and so the browser caches them for a fixed duration (varies between browsers, 2 – 30 minutes).
• OS cache – If the browser cache does not contain the desired record, the browser makes a system call (gethostbyname in Windows). The OS has its own cache.
• Router cache – The request continues on to your router, which typically has its own DNS cache.
• ISP DNS cache – The next place checked is the cache ISP’s DNS server. With a cache, naturally.
• Recursive search – Your ISP’s DNS server begins a recursive search, from the root nameserver, through the .com top-level nameserver, to Facebook’s nameserver. Normally, the DNS server will have names of the .com nameservers in cache, and so a hit to the root nameserver will not be necessary.

Here is a diagram of what a recursive DNS search looks like:

One worrying thing about DNS is that the entire domain like wikipedia.org or facebook.com seems to map to a single IP address. Fortunately, there are ways of mitigating the bottleneck:

• Round-robin DNS is a solution where the DNS lookup returns multiple IP addresses, rather than just one. For example, facebook.com actually maps to four IP addresses.
• Load-balancer is the piece of hardware that listens on a particular IP address and forwards the requests to other servers. Major sites will typically use expensive high-performance load balancers.
• Geographic DNS improves scalability by mapping a domain name to different IP addresses, depending on the client’s geographic location. This is great for hosting static content so that different servers don’t have to update shared state.
• Anycast is a routing technique where a single IP address maps to multiple physical servers. Unfortunately, anycast does not fit well with TCP and is rarely used in that scenario.

Most of the DNS servers themselves use anycast to achieve high availability and low latency of the DNS lookups.

3. The browser sends a HTTP request to the web server

You can be pretty sure that Facebook’s homepage will not be served from the browser cache because dynamic pages expire either very quickly or immediately (expiry date set to past).
So, the browser will send this request to the Facebook server:

GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

The GET request names the URL to fetch: “http://facebook.com/”. The browser identifies itself (User-Agent header), and states what types of responses it will accept (Accept and Accept-Encoding headers). The Connection header asks the server to keep the TCP connection open for further requests.
The request also contains the cookies that the browser has for this domain. As you probably already know, cookies are key-value pairs that track the state of a web site in between different page requests. And so the cookies store the name of the logged-in user, a secret number that was assigned to the user by the server, some of user’s settings, etc. The cookies will be stored in a text file on the client, and sent to the server with every request.

There is a variety of tools that let you view the raw HTTP requests and corresponding responses. My favorite tool for viewing the raw HTTP traffic is fiddler, but there are many other tools (e.g., FireBug) These tools are a great help when optimizing a site.

In addition to GET requests, another type of requests that you may be familiar with is a POST request, typically used to submit forms. A GET request sends its parameters via the URL (e.g.: http://robozzle.com/puzzle.aspx?id=85). A POST request sends its parameters in the request body, just under the headers.

The trailing slash in the URL “http://facebook.com/” is important. In this case, the browser can safely add the slash. For URLs of the form http://example.com/folderOrFile, the browser cannot automatically add a slash, because it is not clear whether folderOrFile is a folder or a file. In such cases, the browser will visit the URL without the slash, and the server will respond with a redirect, resulting in an unnecessary roundtrip.

4. The facebook server responds with a permanent redirect

This is the response that the Facebook server sent back to the browser request:

HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
      pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
      path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0

The server responded with a 301 Moved Permanently response to tell the browser to go to “http://www.facebook.com/” instead of “http://facebook.com/”.

There are interesting reasons why the server insists on the redirect instead of immediately responding with the web page that the user wants to see.
One reason has to do with search engine rankings. See, if there are two URLs for the same page, say http://www.igoro.com/ and http://igoro.com/, search engine may consider them to be two different sites, each with fewer incoming links and thus a lower ranking. Search engines understand permanent redirects (301), and will combine the incoming links from both sources into a single ranking.
Also, multiple URLs for the same content are not cache-friendly. When a piece of content has multiple names, it will potentially appear multiple times in caches.

5. The browser follows the redirect

The browser now knows that “http://www.facebook.com/” is the correct URL to go to, and so it sends out another GET request:

GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com

The meaning of the headers is the same as for the first request.

6. The server ‘handles’ the request

The server will receive the GET request, process it, and send back a response.
This may seem like a straightforward task, but in fact there is a lot of interesting stuff that happens here – even on a simple site like my blog, let alone on a massively scalable site like facebook.

• Web server softwareThe web server software (e.g., IIS or Apache) receives the HTTP request and decides which request handler should be executed to handle this request. A request handler is a program (in ASP.NET, PHP, Ruby, …) that reads the request and generates the HTML for the response. In the simplest case, the request handlers can be stored in a file hierarchy whose structure mirrors the URL structure, and so for example http://example.com/folder1/page1.aspx URL will map to file /httpdocs/folder1/page1.aspx. The web server software can also be configured so that URLs are manually mapped to request handlers, and so the public URL of page1.aspx could be http://example.com/folder1/page1.
• Request handlerThe request handler reads the request, its parameters, and cookies. It will read and possibly update some data stored on the server. Then, the request handler will generate a HTML response.

One interesting difficulty that every dynamic website faces is how to store data. Smaller sites will often have a single SQL database to store their data, but sites that store a large amount of data and/or have many visitors have to find a way to split the database across multiple machines. Solutions include sharding (splitting up a table across multiple databases based on the primary key), replication, and usage of simplified databases with weakened consistency semantics.

One technique to keep data updates cheap is to defer some of the work to a batch job. For example, Facebook has to update the newsfeed in a timely fashion, but the data backing the “People you may know” feature may only need to be updated nightly (my guess, I don’t actually know how they implement this feature). Batch job updates result in staleness of some less important data, but can make data updates much faster and simpler.

7. The server sends back a HTML response

Here is the response that the server generated and sent back:

HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT

2b3
��������T�n�@����[...]

The entire response is 36 kB, the bulk of them in the byte blob at the end that I trimmed.
The Content-Encoding header tells the browser that the response body is compressed using the gzip algorithm. After decompressing the blob, you’ll see the HTML you’d expect:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"   
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" 
      lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...

In addition to compression, headers specify whether and how to cache the page, any cookies to set (none in this response), privacy information, etc.

Notice the header that sets Content-Type to text/html. The header instructs the browser to render the response content as HTML, instead of say downloading it as a file. The browser will use the header to decide how to interpret the response, but will consider other factors as well, such as the extension of the URL.

8. The browser begins rendering the HTML

Even before the browser has received the entire HTML document, it begins rendering the website:
 

9. The browser sends requests for objects embedded in HTML

As the browser renders the HTML, it will notice tags that require fetching of other URLs. The browser will send a GET request to retrieve each of these files.
Here are a few URLs that my visit to facebook.com retrieved:

• Imageshttp://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
  http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
  …
• CSS style sheetshttp://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
  http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
  …
• JavaScript files
  http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
  http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
  …

Each of these URLs will go through process a similar to what the HTML page went through. So, the browser will look up the domain name in DNS, send a request to the URL, follow redirects, etc.
However, static files – unlike dynamic pages – allow the browser to cache them. Some of the files may be served up from cache, without contacting the server at all. The browser knows how long to cache a particular file because the response that returned the file contained an Expires header. Additionally, each response may also contain an ETag header that works like a version number – if the browser sees an ETag for a version of the file it already has, it can stop the transfer immediately.

Can you guess what “fbcdn.net” in the URLs stands for? A safe bet is that it means “Facebook content delivery network”. Facebook uses a content delivery network (CDN) to distribute static content – images, style sheets, and JavaScript files. So, the files will be copied to many machines across the globe.
Static content often represents the bulk of the bandwidth of a site, and can be easily replicated across a CDN. Often, sites will use a third-party CDN provider, instead of operating a CND themselves. For example, Facebook’s static files are hosted by Akamai, the largest CDN provider.
As a demonstration, when you try to ping static.ak.fbcdn.net, you will get a response from an akamai.net server. Also, interestingly, if you ping the URL a couple of times, may get responses from different servers, which demonstrates the load-balancing that happens behind the scenes.

10. The browser sends further asynchronous (AJAX) requests

In the spirit of Web 2.0, the client continues to communicate with the server even after the page is rendered.
For example, Facebook chat will continue to update the list of your logged in friends as they come and go. To update the list of your logged-in friends, the JavaScript executing in your browser has to send an asynchronous request to the server. The asynchronous request is a programmatically constructed GET or POST request that goes to a special URL. In the Facebook example, the client sends a POST request to http://www.facebook.com/ajax/chat/buddy_list.php to fetch the list of your friends who are online.
This pattern is sometimes referred to as “AJAX”, which stands for “Asynchronous JavaScript And XML”, even though there is no particular reason why the server has to format the response as XML. For example, Facebook returns snippets of JavaScript code in response to asynchronous requests.

Among other things, the fiddler tool lets you view the asynchronous requests sent by your browser. In fact, not only you can observe the requests passively, but you can also modify and resend them. The fact that it is this easy to “spoof” AJAX requests causes a lot of grief to developers of online games with scoreboards. (Obviously, please don’t cheat that way.)

Facebook chat provides an example of an interesting problem with AJAX: pushing data from server to client. Since HTTP is a request-response protocol, the chat server cannot push new messages to the client. Instead, the client has to poll the server every few seconds to see if any new messages arrived.
Long polling is an interesting technique to decrease the load on the server in these types of scenarios. If the server does not have any new messages when polled, it simply does not send a response back. And, if a message for this client is received within the timeout period, the server will find the outstanding request and return the message with the response.

Conclusion

Hopefully this gives you a better idea of how the different web pieces work together.

OOPS : Can we have Sealed Method in abstarct class ?

Looking at first site the The Keyword Sealed & Abstract are contradictory to each other..In simple terms we can Say Answer is NO...

Look the code below

using System;

abstract class A
{
public abstract void Hello();
public sealed void Hi();
}

when we will complie the code.. we will get the Compile time Error as below

'A.Hi()' cannot be sealed because it is not an override..

But the Crux is We can have Sealed methods in abstract class when the abstract class is Dervided class .. for Eg.

using System;

class A
{
public virtual void Hello()
{
Console.WriteLine(" Say Hello");
}

}

abstract class B : A
{
public sealed override void Hello()
{
Console.WriteLine(" Say Hi");
}

}

class C : B
{

}


class Demo
{
public static void Main()
{
C c1 = new C();
c1.Hello();// Output is Say Hi
}
}


// Thanks

OOPS : New vs Override keyword

using System;

using System.Data;

using System.Text;

using System.Windows.Forms;


namespace BaseDerive

{

    public partial class Form1 : Form

    {

        public Form1()

        {

            InitializeComponent();

        }


        private void Form1_Load(object sender, EventArgs e)

        {


            BaseClass b = new BaseClass();

            b.func1();


            DeriveClass d = new DeriveClass();

            d.func1();


            //Calls Base class function 1 as new keyword is used.

            BaseClass bd = new DeriveClass();

            bd.func1();


            //Calls Derived class function 2 as override keyword is used.

            BaseClass bd2 = new DeriveClass();

            bd2.func2();


        }

    }


    public class BaseClass

    {

        public virtual void func1()

        {

            MessageBox.Show("Base Class function 1.");

        }


        public virtual void func2()

        {

            MessageBox.Show("Base Class function 2.");

        }


  public void func3()

        {

            MessageBox.Show("Base Class function 3.");

        }

    }


    public class DeriveClass : BaseClass

    {

        public new void func1()

        {

            MessageBox.Show("Derieve Class fuction 1 used new keyword");

        }


        public override void func2()

        {

            MessageBox.Show("Derieve Class fuction 2 used override keyword");

        }


public void func3()

        {

            MessageBox.Show("Derieve Class fuction 3 used override keyword");

        }


    }

}

This is a window application so all the code for calling the function through objects is written in Form_Load event.
As seen in above code, I have declared 2 classes. One works as a Base class and second is a derieve class derived from base class.

Now the difference is

new: hides the base class function.
Override: overrides the base class function.

BaseClass objB = new DeriveClass();

If we create object like above notation and make a call to any function which exists in base class and derive class both, then it will always make a call to function of base class. If we have overidden the method in derive class then it wlll call the derive class function.

For example…

objB.func1(); //Calls the base class function. (In case of new keyword)

objB.func2(); //Calls the derive class function. (Override)

objB.func3(); //Calls the base class function.(Same prototype in both the class.)

Note:
// This will throw a compile time error. (Casting is required.)

DeriveClass objB = new BaseClass(); 

//This will throw run time error. (Unable to cast)

DeriveClass objB = (DeriveClass) new BaseClass(); 

MVC Questions Explored

MVC

Method Group Conversion

Method Group Conversions (delegates)

C# 2.0 includes a feature called method group conversion that simplifies the syntax used to assign a method to a delegate. Method group conversion allows you to assign the name of a method to a delegate, without the use new or explicitly invoking the delegate's constructor.

The Old Way

public class MethodGroupConversion
{
  public delegate string ChangeString(string str);
  public ChangeString StringOperation;

  public MethodGroupConversion()
  {
    StringOperation = new ChangeString(AddSpaces);
  }

  public string Go(string str)
  {
    return StringOperation(str);
  }

  protected string AddSpaces(string str)
  {
    return str + " ";
  }
}

The New Way

We replace the constructor with a more straightforward assignment:

public MethodGroupConversion()
{
  StringOperation = AddSpaces;
}

Usage of Finally block

Classic example is closing a database connection

no matter whether the SQL operation was successful or generated an exception.

In such a case, you can use the optional finally block

try

{

// Open a database connection

// Execute SQL statement

}

catch (DbException ex)

{

// Handle database exception

}

finally

{

// Close database connection if it exists

}

Troubleshooting Applications with IIS Logs

Have you ever tried to troubleshoot or debug an application without having ever seen the code? Have you ever had a malfunctioning application, and neither the browser nor the application provided a useful error code?
I’ve encountered both scenarios many times, and it’s a good idea to be prepared for their eventuality. The techniques I’ll describe in this article will help you troubleshoot any application or system running under IIS, no matter what platform it’s coded on. These techniques have helped me troubleshoot applications and Web sites in a variety of situations, especially on devices other than PCs—a scenario that is becoming the norm these days. In a recent case, these techniques helped me discover why videos wouldn’t display on Apple devices though they ran perfectly on Windows-based devices.

Some Considerations

There are many valid techniques for debugging ASP.NET and other Web applications running under IIS. The browser itself often produces a specific error or set of errors that is enough to resolve the issues.
But suppose that information isn’t enough? This is where it becomes handy to know a few extra techniques. The simplest of these is also one of the quickest and best-known—running the application directly on the server. Sometimes the servers aren’t configured for this option, but if you can do it, the server will generally provide more useful debug information than an outside machine. This behavior is obviously built-in by Microsoft for security purposes. To get even more data on a server’s browser, turn off the “Show friendly HTTP error messages” option, which you’ll find in Internet Explorer, under Internet Options | Advanced.
Sometimes you’ll need more information, and that’s when logging becomes essential. Microsoft has built powerful logging facilities into its servers, which will help immensely on any troubleshooting quest, assuming you know what to look for, and where.

Turning on IIS Logging

The first step is to turn on Windows logging on the server. There are several ways to do this. The actual steps can vary (sometimes greatly) depending on which version of Windows Server is running.
Delving into those steps or describing the drawbacks and advantages of each is beyond the scope of this article. Here, I’ll simply point out that to properly use logging to debug your applications, you must turn it on before the actual errors occur. You’ll find a lot of useful information in these two MSDN articles for Windows Server 2003 and 2012: “How to configure Web site logging in Windows Server 2003” (bit.ly/cbS3xZ) and “Configure Logging in IIS” (bit.ly/18vvSgT). If these don’t meet your needs, there are plenty of other online articles relevant to turning on logging in IIS for other versions of Windows Server.

Determine the Proper ID Number

Once logging is on, you need to find out the ID number in IIS of the Web site you’re troubleshooting. This is crucial, as servers typically host more than one Web site, and trying to find the log folder manually can be daunting. (I attempted it on a server running 45 Web sites and it was almost impossible.)
Open IIS Manager to display all Web sites being hosted. For this example, suppose I’m attempting to find out why WebSite2 suddenly stopped working or is only working intermittently.
As you can see in Figure 1, the ID for WebSite2 is “3.” The next step is to open the corresponding log folder, which is typically (but not always) found in the Inetpub folder. Windows usually creates this folder in the root (C:) of the server, but in my case, the Inetpub folder is on the D: drive. Industry best practices advise keeping code and OS drives separate for easy swapping in case of failure.

Figure 1 Finding the Web Site ID Number
Windows names all logging folders W3SVC#, where # is the ID of the given Web site. Because the ID of the site being debugged in this case is 3, the log files are located in a folder named W3SVC3, as shown in Figure 2.

Figure 2 Opening the Log-File Folder

Browse the Files

When you open the correct folder, you may see a lot of files. IIS usually keeps many different files, depending on how you’ve configured the server history or how long logging has been on. To find the file you need, an almost-sure bet is to scroll to the bottom of the list and open the last file, though if you have the exact time the error occurred, you can locate the file using the date and time in the name of the file. Either way, open the file using a file editor such as Notepad.exe.
You’ll probably see a lot of data in the file. At first glance, the information might seem cryptic and useless, but with a little study you can find plenty of gems buried within this data. I’ll look at some of the most useful data elements recorded by the logging process.
IIS and Windows log an individual line for each HTTP request. A typical line looks like this:

2013-08-28 00:01:12 128.128.128.20 GET /default.asp - 443 - 200.200.200.17 Mozilla/4.0+(compatible; +MSIE+8.0; +Windows+NT+6.1; +WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+InfoPath.3;+MS-RTC+LM+8; +.NET4.0C;+.NET4.0E; +.NET+CLR+1.1.4322) 200 0 0 15

This is a line from an actual IIS log. The data shown here is in one of the “standard” formats. However, because this option is highly configurable, there’s no guarantee your files will look exactly like my sample. Instead of wading through all the data, I’m going to focus here on the elements that are of most interest to debugging an application.
The first bolded element in the sample is the date of the request. Keep in mind this is the server date. As many Web applications run worldwide across many servers deployed in different time zones, this date can be misleading. Make sure the date accurately reflects the actual time the errors occurred. Many servers use GMT time, but you should validate the format.
Next, you’ll see the IP address that was accessed, the HTTP operation type (GET) and the actual file requested or accessed. In the following sample line, the code is calling the default.asp file:

128.128.128.20 GET /default.asp

This information is valuable, as there may already be errors occurring at this stage of the process. For example, you might be expecting another file to be executed at this point.
The next part of the line shows the IP address where the request originated, as well as the receiving port:

443 - 200.200.200.17

This information is also important, as sometimes it’s necessary to verify that the request you’re troubleshooting actually came from a known source.
As you can see, the actual port used is also referenced. This seemingly unimportant bit of information is vital when looking for issues. For example, the firewall may not be configured correctly. This data is followed by a lot of information, mostly related to versions:

+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2; +.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729; +InfoPath.3;+MS-RTC+LM+8; +.NET4.0C

For example, you can see whether the browser is running 32- or 64-bit, the CLR versions (for those who delve that deeply into the .NET universe), and the actual .NET version installed on the server (in this case, .NET 4 C).

Get to the Bottom of Things 

Up to this point, I’ve shown the relatively obvious parts of the log file entry. Most importantly, you can see which browser is responding to the HTTP request. Sometimes this will suffice, as different browsers may produce different results. Here are some partial strings showing what Firefox and Chrome might look like in the file:

;+rv:17.0)+Gecko/20100101+Firefox/17.0 404 0 2 109
+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/­28.0.1500.95+Safari/537.36 200 0 0 125

It can be difficult to detect which of several HTTP requests is being debugged because they all look similar. This is where changing the browser can come in handy. By adding an entry from a different (and unexpected) browser, such as Safari or Opera, it can be easier to find and consequently troubleshoot the entry in question.
Finally, take a look at the last four items on the line:

200 0 0 15

The last number, 15, is the response time (in milliseconds) of the HTTP request. This is a very useful piece of information. Knowing how long a request took to process can help you decide whether a given code snippet, Web service or process is taking the desired or “normal” amount of time.
It may surprise you to discover relatively simple steps in a process are taking unexpected processing time. In a recent case, an application sometimes logged in and sometimes failed to log in, without producing a trappable browser error—or any error at all. It just failed. After reviewing the response times in the log, the developers discovered this property in the web.config file:

<add name="CacheProfile1" duration="30" />

The value of this parameter, apparently harmlessly set to 30 seconds, was simply too large. Once it was reduced, the application worked as expected.
Now (repeating the line here for clarity) I’ll zero in on one of the most important parameters from the set I’m reviewing. The first item, 200, is the actual HTTP response from IIS:

200 0 0 15

That HTTP response code, 200, means success. Often, you’ll encounter a known error type, such as 404 (not found) or 500 (internal server error) and that may give you enough information to troubleshoot and resolve an issue. For an official list of HTTP status codes, visit bit.ly/17sGpwE.
I’ll now relate one more real-world case—the one that actually prompted me to share this article. I had a Web site that worked and executed perfectly on PCs, but as soon as the users accessed the site on their iPad devices, video streaming simply didn’t work. To make things worse, there was no error code; the video just refused to function.
This is where troubleshooting with the logs proved invaluable. By checking the logs and verifying the HTTP request was being made from Safari (to isolate the request), I discovered the server reported a 404 error. The error message was confusing and the error itself seemed implausible, as the PC version of the site worked perfectly.
Though the logs were reporting the object wasn’t being found, I knew very well the files were in place. This prompted me to review the different ways iOS and Windows handle and store files. As I explored the source code that loaded the video, I discovered that the actual path to the video files had been hard-coded in the source, and that the path didn’t exist in iOS iPad devices. That was the reason for the 404.
It’s important to note here that all the symptoms pointed elsewhere. For example, such a problem is typically resolved by checking for the existence of unsupported media types (or Multipurpose Internet Mail Extensions [MIMEs]) in IIS. However, if the problem were a missing MIME type, the error code would have been an HTTP 415 (unsupported Media type) or a similar error, and the logs didn’t report that. Debugging using the IIS logs proved instrumental in finding the problem. I saved a significant amount of time by seeing the actual error code and investigating it, rather than chasing after what would have initially seemed more likely. Once again, knowing how to read the logs saved the day.

Wrapping Up

Log files can be a powerful tool for debugging and troubleshooting applications, even in “blind” situations, provided you know where to find them and what the data means. Investigating the data in the logs is one of the simplest—yet more sophisticated and complete—methods you’ll find to resolve issues.
It takes a little practice and certainly some discipline, but once you’re comfortable with these techniques, you should be able to debug and resolve most application and IIS issues. I’ve put these techniques to good use, and so can you


Source : http://msdn.microsoft.com/en-us/magazine/dn519926.aspx