Finger Pointing Internet Style

This morning was spent diagnosing problems with a web application. It would be one thing if it were our web application, but It wasn't. It was a 3rd party web application that one of my clients links to. And it didn't work.


Background
This problem has actually been going on for a couple of months. The organization responsible for this web application would provide my client with a link to use to access a landing page specifically designed for the client. My client would then test the link, and send back a message telling them that it was broken. Days or weeks would go by, and the process would repeat itself.


Finally it was getting down to the wire. My client has their own schedule, and this 3rd party application was becoming a problem. So after a flurry of emails, the 3rd party informed my client that everything was ready to go. And initially my client thought it was. Unfortunately it was not.


Problem 1: The Obvious
The first time a person accessed the web application, there is a server error, along with all the cryptic crap that gets spewed when a web application decides to fail, and has no graceful error processing/logging system to avoid exposing its gory details to the user.


This is a fairly common problem. One cause of this type of problem is when a link to a landing page is provided, but it requires specific information to have been previously set up in the user session. Normally users follow fairly predictable paths when accessing a web application. Early in that process, often certain session attributes are initialized for the user, for example an empty shopping cart, and the rest of the site just assumes that this already exists. But when a custom landing page is developed, and that is the first page that the user hits when coming to the site, those session attributes may not exist.


Interestingly, this was not the problem in this particular case. Sessions are often tracked with cookies, and after deleting the cookies from the browser, we discovered that the error screen was not generated. It still may be session related, but seems less likely.


The point of all this is that people who provide web applications should TEST what happens when a user comes into the site fresh. This should not be left as an interesting discovery for the users. 


Problem 2: The Obscure
The second problem occurred when my client tried to access the web application, using the link provided, from different document types. The link was placed in a word document, a PDF file, a web based email system, an Outlook based email system, and in another web page. In all cases, except the PDF file and Outlook, the link did not take the user to the correct page. The interesting thing was that doing a copy and paste of the link into the browser directly worked!


After some debugging (thanks to Firefox/Firebug), we determined that the only difference between the sequence of 4 pages that were redirected in the initial landing page was in the http header "referrer" field. Our tentative conclusion is that the web application is somehow sensitive to the referrer field, and is broken if that is set. One user of the referrer field is to control third party access to server resources, i.e. verify that the referrer is authorized to access the resource. This is just the opposite, here the referrer must be non-exist ant for the application to work.


Lessons Learned
The lesson for web application developers here? Test access to published links using a variety of different clients. And not just browsers, also client applications such as Microsoft Word, PDF files, email clients etc.


I hate to leave this discussion without definitive answers to the problems, but the truth is that since it is not our web application, there is only so much we can do. We isolated the fault domain (the 3rd party application), and provided them with sufficient documentation and test scenarios that they should be able to reproduce the problem. Whether they do so, fix the problem, and test the result remains to be seen.