SharePoint: Quick Troubleshooting Tip: HTTP Response Headers

Posted On December 30, 2018

Often in troubleshooting SharePoint, we’re interested to know on which Web-Front-End (WFE) a certain request landed. When you have multiple WFEs that are load balanced, this is not easily discernable.

One trick is to edit your HOSTS file and point the load balanced URL at the IP address of one WFE. That method certainly has its place, especially when trying to figure out if a certain behavior or error only occurs on some WFEs, but it doesn’t fit every scenario. For example, what if you’re trying to figure out if your load balancer is bouncing you between WFEs?  Or what if you’re trying to simplify log gathering by only getting logs from the server that processed the request?

 
 

Here’s a method that involves my personal favorite web troubleshooting tool: Fiddler.

Note: This will work with any other web traffic / network capture tool as well. I just happen to like Fiddler.

I’m usually using Fiddler for capturing web traffic anyway, so adding more information to the output only helps.

Here’s what you do:

In IIS Manager, select the IIS site used by your target SharePoint web application and double click on HTTP Response Headers.

 
 

 
 

You’ll see that there are some already present:

 
 

Choose Add

Give the Response Header a name. It’s going to be used to denote which WFE you’re hitting, so it makes sense to name it “server” or “wfe”, or something like that.

As a general rule, keep your response header name simple.  And whatever you do, do not put a space in it, for example: “Server Name”.  Doing so will break WebDav calls (Propfind, Options, etc) and cause Office client interaction with SharePoint to fail.  If you must use multiple words in a Response Header name, separate them with a dash: “Server-Name”.

Then give the header a value. You don’t have to (and shouldn’t) use the servers actual name.  Just use something that will be unique and help you identify which server it is. For example, maybe you have two load-balanced WFEs with names “PROD-AWG-WEB01”, and “PROD-AWG-WEB02”. You could use “WFE1” and “WFE2” (respectively) for the values.

Now you want to add the same HTTP Response Header to the same IIS site on your other WFEs. The only difference will be the value. For example, on “PROD-AWG-WEB02”, you would use something like “WFE2”, and so on.

 
 

Then, when you’re troubleshooting, you can take a Fiddler trace and immediately tell which WFE a given request went to.

While you’re looking at Response Headers in Fiddler, it’s also useful to notice that the value for the “SPRequestGUID” Response Header is the Correlation ID for the request.

Now you can gather just the one SharePoint ULS log from the one WFE, and you also have the Correlation ID to filter it by.

Finding the proper request within a SharePoint ULS log doesn’t get much easier than that.