David Dallet’s weblog

The Hyper Text Transfer Protocol defines various status codes/error codes.

Amongst them, the most frequent are the 200 code (OK: no error), the 404 error (document not found) and the 301/302 redirections.
There is also the 401 status, which is used for HTTP Authentication.

The server may return the 401 status code when you try to access a page, but also when your browser try to access images embed in a page with the img tag. This blog post deals with some unwanted browser behaviour that may occur with “images” returning a 401 status code.

Scenario

What I try to study is just how the browser behave when it loads a page referencing an important number of “pictures” (xhtml/html img element) returning a 401 status code.

The 401 status code could either be intentional or result of a misconfiguration of the server hosting the pictures.

I focus here on testing with “images”, although CSS, external javascript code, [i]frames and a lot of other techniques are likely to have a similar effect.

Behaviour observed in Mozilla firefox 3.0.6 (running on kubuntu 8.04) and Epiphany 2.22

It’s not nice at all.

If there are 40 “images” returning a 401 status, there may be 40 username/password prompts. The number of prompts is not the real problem however.

A minor problem is that it is impossible to navigate correctly inside a page during a prompt, before pressing the “cancel” button. (Although you may think “well, this page contains references invalid images after all”, it is still a problem : for example if an annoying guy posts 200 [img] tags inside his post on a forum.)

A major problem is that it is impossible to access the browser menu or to switch tab before closing the 40 (or more…) dialog boxes. Any browser able to manage multiple tabs should be designed to avoid a “crash” (or an unusable state) when one or more tabs are associated with invalid content.

With other OSes, other browsers…

To be completed… Don’t hesitate to tell what you get, I’m waiting for your comments.

Doing the test

You may test your browser by visiting a test page on this blog at http://www.ddmdllt.org/weblog/posts/2009/02/27/firefox-problem-demo-password-protected/.

Warning : This page may obviously cause a bad behaviour from your web browser. Proceed at your own “risk”. You are likely to just have to click 10 times on “cancel” before being able to leave.

To avoid accidental visits, the post is password protected. The password is “iKnowWhatIAmDoing” (copy/paste, without the quotes).

(I noticed that some people tried to break the password. I’ll just say them that I don’t plan to use wordpress password protected posts to put private things here.)

A bug? So where is the bug report?

I’ve filled a bug report on launchpad. Since some people have told me that the problem appear with other OSes, it would be worth reporting it in other places… However, a discussion on the #firefox IRC channel (on freenode) learned me that this problem is known for a long time (and still not fixed). A very quick search on bugzilla show me that a related bug is reported at least since 2003.

Quotation (Comment #5 From Chris Casciano):

“at no point in the series of 10 dialogs can you interrupt, you just have to cancel through all 10. At 10 it becomes a chore, at 50 it becomes a denial of use.”