My confusion was that you posted this in the linux forum regarding an error with ISA. So is the problem on your end because you run windows ISA servers (firewall/reverse proxy) or is it the users that connect to you from within an organization that has ISA servers providing the proxy services for them.
Unfortunately the problem is that we are not in a constrained enviornment where we can expect our visitors to make any changes in order to view our site. Is there anything we can do on our end to fix this issue? What is causing it??
So, I got some initial feedback back as well. The registry settings that CimmerianX provided is documented on a few forums out there. Unfortunately, with regard to the cause of the problem, I wasnt able to get much information back. In a scenario such as this, I would typically open a premier support case with Microsoft so that a capture could be analyzed by a support engineer to determine the cause of this issue.
This issue could be specific to the version of ISA that visitor is passing through, may have been fixed in new versions of ISA.
Unfortunatley, there isnt a clear documented response on the Internet regarding the cause of this issue, or at least, I couldnt find one and my ISA contacts have not encountered this as of yet.
This Wiki is an interesting read, and it specifically discusses Header Fields and Responses. I know you won't need to read most of that because you work with it every day. But, I just wondered if the problem could possibly be related to any of the details sent as "Common Non-standard Response Headers"
Finally, is there any data of whatever description requesting to be cached on their server, or vice versa, that is being rejected? A "Response Header" there is no place for will be a "Response Header" too long. Caching is discussed in the same article here,"Avoiding Caching".
Based on what is reported online, this issue can be resolved by tuning the configuration of the ISA server. I would not suggest that the appropriate action is to modify anything on the daniweb side unless you are getting reports that there is an issue being experienced by users in various scenarios. If the only set of users that have reported this are behind an ISA server, i think it be appropriate to specifically figure out what it is the this ISA server does not like. For all you know, the users behind this ISA server are experiencing the same issue when visiting other sites.
Agree from JorgeM. Don't fix their problem by changing your code that works for 99.9% of the visitors out there. The issue is documented to be a misconfigured ISA. I would poilitly point that fix out to them as being "in their best interest to implement".
I would poilitly point that fix out to them as being "in their best interest to implement".
But the problem is that we are not in a closed environment. Someone comes in from a Google search. The page doesn't load. They leave, never to be heard from again. Thankfully, I was able to hear about once such documented case of this happening, where the person was able to troubleshoot for me, but for every one time I find out about it, it happens 100,000 other times that I don't know about.
Understood that as a web admin, you want to make the site as compatible for as many people as possible. But you will always have issues with end users who don't configure their systems correctly.... but I suppose that's obvious.
The issue here is that the HTTP header is refused by ISA. Nothing in the HTML is causing this. So you would need to look at the fields you have defined and try to reduce the overall data being sent.
We looked at that link here. Using your knowledge and experience, what would you say could be the likely culprit in that list if Daniweb chose to make changes in their site handling to accommodate older config's?