Long urls and SpeedTouch 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 anyMeta system to use less slashes in the urls...