While we were working on this problem, we realized that HTTPS traffic does not suffer from the "long url" problem (unless, of course, you have an exceptionally long domain name). This is because the query string of the URL is encrypted in an HTTPS request message and thus wouldn't be visible to a proxy or firewall. While we did adjust the maximum url length setting on our Cisco firewall (which helped), we also realized that our production site will be entirely behind HTTPS, so we won't have to worry about it anymore.
A few months ago, I was having trouble logging in to meta.stackoverflow.com and I e-mailed the Stack Overflow team for help. They pointed me to "I Can't Log In With My OpenID - Troubleshooting Tips" and that led me to believe that I may be behind an aggressive firewall or proxy that blocks long URLs. I also had trouble with other sites that used long URLs.
I'm doing testing with a 3rd party vendor's web site and their site requests
.axd resources with very long query parameters. I've had lots of trouble with the functionality of their site inside our network, so I'm again thinking that a proxy or firewall is interfering.
I'm going to ask our SysAdmin team to look into this "long URL" issue, but I'd like to give them more direction about where to look, if possible. One of our SysAdmins said that he thinks we're behind a Cisco Web Application firewall. Is there a particular setting on this device that we could look at to see if it's blocking long URLs? Are there other common network components to look at to see if they are blocking long URLs?
NOTE: Here are the steps I took to determine that I think the problem is in a network component and not on my personal machine.
The 3rd party vendor's website did not work correctly when I visited their site from:
- IE8, Firefox, or Chrome on my in-domain work PC running Windows XP (Fiddler even showed an HTTP protocol violation when connecting from IE8).
- IE8 & Firefox from an in-domain Windows Server 2k3 terminal server.
- IE8 & Firefox on an in-domain Windows 7 machine with a domain admin logged in.
- IE8 on an out-of-domain Windows 7 personal laptop connected via wired connection to our network.
The 3rd party vendor's website worked correctly when I visited their site from:
- IE8 & Firefox on the same personal laptop mentioned above, but connected via WiFi that does go through our network stack.
Because the lowest common denominator when the site did not work correctly is our corporate network stack, I think the problem likely exists there.