Running into timing issues with HTTPGet HTTPPost
-
We have a web application that is required to use HTTP post and get to pass data back and forth. Under IIS 6 everything works fine. The client receives the response (usually two packets) and everything runs as expected. We moved the application to Visual Studio 2008, IIS 7, and converted our handlers to be properly recognized (not compatibility mode). We still have all of our longer running transactions function normally. However our logoff transaction failed. I ran netstat and saw that with the login transaction that there was a port opened in a CLOSE_WAIT state. The GetResponse method works as expected. The logoff however shows no such port state and when the client goes to read the response it crashes because there is a stream object that goes nowhere. (no port in CLOSE_WAIT state or any other state) I then went to the server side and stepped through our logic to issue the response to the client. In each case I get the status after the respond and it shows 200 OK as the response. Meaning the the transaction was a success and the response was a success. The last thing I do is flush the buffer. The only difference with the logout is that it is probably only 1 packet while even login is at least 2. If I pause the server right after the flush, the client takes off and successfully get the response object. If I do not pause it, the client crashes and no port is sitting in the CLOSE_WAIT state. We really need to get this fixed ASAP. Do I put a thread wait after the flush???? Will that stop the entire web server???? What do I do to get this working? Thanks -- code for the WriteResponse is listed below. Visual Studio 2008 -- IIS 7.0 -- Vista Ultimate with all updates applied
private void WriteResponse(HttpContext context, string response, ReplyCodeEnum reply, string replyText)
{
StringTemplate template = GetResponseTemplate(context, reply);//see who's calling this template.SetAttribute("code", ReplyCodes.GetCode(reply)); template.SetAttribute("text", replyText); template.SetAttribute("response", response); response = template.ToString(); // Finish specifying response headers context.Response.ContentType = "text/xml"; // Write response context.Response.Write(response); // Store content for Http Log context.Items.Add("Content", response); //TODO out string s = context.Response.Status; context.Response.Buffer = true; context.R -
We have a web application that is required to use HTTP post and get to pass data back and forth. Under IIS 6 everything works fine. The client receives the response (usually two packets) and everything runs as expected. We moved the application to Visual Studio 2008, IIS 7, and converted our handlers to be properly recognized (not compatibility mode). We still have all of our longer running transactions function normally. However our logoff transaction failed. I ran netstat and saw that with the login transaction that there was a port opened in a CLOSE_WAIT state. The GetResponse method works as expected. The logoff however shows no such port state and when the client goes to read the response it crashes because there is a stream object that goes nowhere. (no port in CLOSE_WAIT state or any other state) I then went to the server side and stepped through our logic to issue the response to the client. In each case I get the status after the respond and it shows 200 OK as the response. Meaning the the transaction was a success and the response was a success. The last thing I do is flush the buffer. The only difference with the logout is that it is probably only 1 packet while even login is at least 2. If I pause the server right after the flush, the client takes off and successfully get the response object. If I do not pause it, the client crashes and no port is sitting in the CLOSE_WAIT state. We really need to get this fixed ASAP. Do I put a thread wait after the flush???? Will that stop the entire web server???? What do I do to get this working? Thanks -- code for the WriteResponse is listed below. Visual Studio 2008 -- IIS 7.0 -- Vista Ultimate with all updates applied
private void WriteResponse(HttpContext context, string response, ReplyCodeEnum reply, string replyText)
{
StringTemplate template = GetResponseTemplate(context, reply);//see who's calling this template.SetAttribute("code", ReplyCodes.GetCode(reply)); template.SetAttribute("text", replyText); template.SetAttribute("response", response); response = template.ToString(); // Finish specifying response headers context.Response.ContentType = "text/xml"; // Write response context.Response.Write(response); // Store content for Http Log context.Items.Add("Content", response); //TODO out string s = context.Response.Status; context.Response.Buffer = true; context.R -
Thanks Mike. Microsoft suggested first that we try context.Response.Close(); and see if that works. I think it does the same thing but derived from the context object. Michael