Live HTTP Headers Equivalent for IE or Edge 2016

Over the years, my Live HTTP Headers Equivalent for IE post has pretty consistently gotten a few hits a month. Maybe that is because Google still ranks it #2 behind a StackOverflow post from 2010. I decided to update it since the post is from 2007 and what is available has changed.

The original issue was end users having a problem downloading office files from our web site. The issue only happened in IE, so we could not get them to look at headers using Firefox to diagnose the problem. The users did not want to use Firefox or maybe could not at work environments not allowing them to install alternative browsers.

Maybe – Free

Sorted in order I’d probably recommend.

  1. F12 Developer Tools (for Edge; IE Developer Tools) – looks very much like the Web Developer tools for Firefox and Chrome. The Network tab captures which pages are taking forever to load. Click on a specific request displays the request and response headers.
  2. iehttpheaders – Dunno if much has changed, but this was the better of the two from the original 2007 post.

No Way – Free

These are too scary or complicated to be something I would want to have to walk end users through using. Fine for power users, but not my purpose.

  • Fiddler – disappointed the logo is not a crab. Listens in the background and captures all browsers. All our stuff has encrypted traffic which Fiddler can only see by installing a CA called DO_NOT_TRUST, which there is no way I am going to ask clients to do.
  • Wireshark – probably okay for a power user, but not most people in the general public.

No Way – Paid

Not really useful for my purposes because this was about having end users install something to help us figure out the source of their trouble.

  • DebugBar HTTPTab – Looks viable, but it is essentially the same as the F12 Developer Tools. Has issues with other integrations.
  • HTTP Debugger – Sniffs all HTTP traffic.
  • HttpWatch – free version only works with well known sites. Have to get paid version to see our stuff.
  • HTTP Analyzer – trial version. Has a warning the technology it uses likely causes antivirus software to think it is malicious software. Difficult to explain to users, hey, use this thing your computer will likely complain is a virus.
  • IEWatch – IE plugin. Ancient and has not been actively developed in 9 years. Newest OS reported to support is Windows Vista, so it might have issues with more recent ones like 8 and 10?

Host Hopping Cookies

It started with a tweet on Saturday morning.

@MsIngalls: When I go to the Checklist in @Desire2Learn -when I am logged in – I get an error message that says my log in has expired – ideas? #d2l

This sounded like an issue we had in WebCT Vista product I called Failed Sessions. FSes occur when the user is actively working in the product and suddenly gets dumped to the login page. Not to be confused with Login Loop which is providing the correct username and password but never getting a valid session. I hated working either issue because they were never repeatable. The problem could involve any piece of software that could somehow touch a cookie on the user’s computer. Occasionally they were the fault of Weblogic too.

I recommended Amy open a Desire2Learn ticket through our portal on behalf of the professor. I also started my own investigation.

First, I poked around in the logging database for errors involving checklist. I found different courses not the one involved.

Second, I pulled out of our load balancer logs the id number for the course. That yielded plenty of data showing the problem.

These, I added to the ticket and suggested capturing the HTTP headers should the issue not be repeatable by others. Of course, the support agent was not able to repeat it. The headers clearly showed the cookies were not sent.

The professor of course poked holes all through my suggestions of tracking down which of the many software is involved. Different software, hardware, networks, and browsers meant the cause was probably not something residing on the computers. But the issue definitely was still all of these browsers in a wide variety of places all chose not to send the cookies. This is also when he dropped the next bomb that the problem only occurs on links in a specific widget.

Checking the code behind the widget, I only saw simple absolute URLs. Which made me shudder because earlier this week absolute URLs in the login page for a development site put me in production without me being aware for several minutes.

PSA: Only use absolute URLs when sending a visitor to another web server. Say you are here, at www.ezrasf.com and you want someone to see another of my blog entries. Drop http://www.ezrasf.com from the URL and start the path with / (a relative URL). Should I change the host name to blog.ezrasf.com or www.ezrafreelove.com, then the link has better success of working.

It turns out the problem is the professor used the pre-production host name for the web application. The widget absolute URL links used a different host name for production. Both resolve to the same servers. But cookies are tied to a specific host name. So being logged into one of host and getting a link to the variant means the session is not valid at the variant.

At least the workaround and fix are easy.

The workaround for the professor is to stop using the pre-production URL.

The fix is for the widget designer to turn the absolute URLs to relative URLs since they point to same location.

Also, it would be nice for a better error message than:

No Login

Either you have failed to login, or your login has expired.

First the comma is bad grammar. Second, if I am a normal user who encounters this problem, then what can I do to fix it myself? This is not an error someone sees if their password or username are wrong. This is also not what a user normally sees when they are idle too long. But then again, there are lots and lots of potential causes and solutions.