Last post Dec 07, 2007 01:12 PM by supercal5
Feb 25, 2006 05:50 PM|philmccracken|LINK
I have quite the stumper on my hands so I dare you to solve this for me. I have a sign up process on an HTTPS site that, after entering their data, customers click submit, wait a good couple minutes with a spinning browser logo etc, and
finally get "page cannot be displayed". Recorded in the web log files is a 400 Error on their POST request. Nobody internally has been able to replicate and we have tons and tons of folks using and submitting the form with no problem. Those folks who get
the problem are using a wide variety of browsers (some were IE 6, win XP). One said they tried in firefox and got the same thing. All of them claim to have used this form back when it was ASP.NET 1.1 and not 2.0 like it is now. The server is windows 2003
web edition with IIS 6.
Without running a packet sniffer on my production server and getting these customer to "try it" while the sniff is in progress, can anyone think of anything I can do? Is there something buggy in .net 2.0?
Feb 25, 2006 07:11 PM|NC01|LINK
Is there something buggy in .net 2.0? Don't you think that everyone would get the error then?
I've seen many cases of screwy things that happen on some people's browsers and can't be duplicated and it's usually fixed by having that user clear his browser cache and the problem goes away.
With the information given, it would be almost impossible to diagnose the problem (other than the suggestion that I made above).
Feb 25, 2006 08:06 PM|philmccracken|LINK
Right, but these are multiple people with different browsers, in different locations, at different times and those of them using this particular form all claim to have been able to do so before the .net 2.0 upgrade. I guess the only way really is to get
one of them, who's having the problem, use the form at a predesignated time, so I can get a trace of the send/receive to determine why its triggering a 400 error.
The interesting thing is, it's a 3 step process on the same web form. Step 1 is a bunch of check boxes (ie "yes, I agree to your terms"), then the postback hides that placeholder and activates the Step 2 placeholder where the customer enters their information,
and its consistently step 2 of that process where the 400 is logged. So that would imply something is wrong with the page/code right?; except that it's only a handful out of thousands who are submitting the form with no problems. And in all cases, they're
all logging 400 bad request in the web log (and there's another IIS log in \system32\logfiles where the 400 shows up; I forgot the name of the file).
So I don't think it's purely a client side issue; though perhaps it's a combination of factors.
Anyone else want to take a stab?
Sep 18, 2006 09:52 PM|philmccracken|LINK
Hello Guru's and Guru-ettes,
I figured I'd update this thread with some more info and maybe someone will think of something. I called Microsoft product services and got a clean bill of health from the server group, based on a netmon trace, that the server is doing what its supposed
to be doing and there is nothing wrong with our code. They suggested the problem lies somewhere between our web server and the client (like our firewall causing the problem). So, once again, the problem happens to random folks, and not very often (although
its consistent for those folks) - always step 2 when data is POSTed back to the server. We replicated our entire HTTPS site on HTTP and so far, everyone who hasn't been able to, can get past that point using the HTTP site. So whatever the problem is, it's
directly related to HTTPS/SSL. We have a thawte certificate, which should be groovy. So what gives?
Dec 29, 2006 12:32 PM|ShahzadAhmed|LINK
im also having the same issue with one of my web service . Rest are working fine even that web service working fine on other pages but only 1.
I have tried various solutions but unable to get success.
Dec 30, 2006 10:38 AM|NC01|LINK
With the information given, it is virtually impossible to give a solution. I'd also say that posting the related code would not be possible as it would be too large to be useful. My suggestion would be to re-write that web service from scratch.
Jun 21, 2007 07:00 AM|pomeara|LINK
Was this resolved ? and if so what was the resolution
Jun 21, 2007 02:28 PM|philmccracken|LINK
We've pretty much tried everything. At one point we set up an HTTP mirror of the https just for folks with the problem and they *still* had the problem. The current thinking is it's some brand of router causing it, but we've never been able to get a customer
willing to spend time troubleshooting with us. So we've just been accepting their info via phone in those rare cases. I did run a packet sniffer and sent a trace to microsoft who gave me the green light that our server was set up correctly and that an incomplete
response was being received from the client side for whatever reason. So in my book, pretty much no resolution. It's nice to know we're not the only ones who have experienced this. :)
Dec 07, 2007 01:12 PM|supercal5|LINK
Do you see Timer_EntityBody errors logged in windows/system32/logfiles/httperr/ for these requests?