Long urls and SpeedTouch modems

We spent some long hours chasing a problem. Some of our users were not able to log on to our web sites. The cause of the problem turned out to be, surprise, SpeedTouch ADSL modems.

We quickly found out that the problem was related the IP address of the user. As some users' laptops did work at their office, but not at their home.

Weird.

Testing Long Urls

We then checked our server logs, and found that the machines of the affected users did not even try to load some JavaScript libraries.

Some library and css files were requested, some were not at all. No mention of the longer urls in our logs whatsoever, none, nada.

Different user agents, using different machines, from the same IP address all showed the same problem.

So we started to make a test script that tried to load JavaScript libraries using different urls. After some versions of our script we found an interesting pattern.

What is the difference between these two urls:

www.example.com/jstest/f/TEST/library/Ajax/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/test21.js

and:

www.example.com/jstest/f/TEST/library/Ajax/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/dir/test22.js

The big difference is that the first one does load and the second one does not load. Ok, the last one is a bit longer, so rest assured that the following url does load as well:

www.example.com/jstest/f/TEST/library/Ajax/somelangurltext-somelangurltext-somelangurltext-somelangurltext-somelangurltext-somelangurltext-somelangurltext-somelangurltext-somelangurltext/test12.js

Conclusion

It is not the length of the url, but the number of directories in the url. The break point seems to be around 19 directory levels.

It all seems to be related to the Web Browsing Interception feature of SpeedTouch modems. Besides that that option makes the modem around 30% slower, it also intercepts some long javascript or css url lookups.

We updated our CMS to use less slashes in the urls...