3.0.4

http Post bug in IE

There is a long standing bug in IE where the http header content length is not equal to the amount of bytes being sent via IE. IE actually sends an extra 2 bytes(CRLF). Many programs have a built in workaround to fix the problem when it sees the user agent is = IE. Well the problem is....when doing a post in AW... the user agent header is set to IE but AW actually is passing the right number of bytes which creates a problem if the server is waiting for the missing bytes.

I hope that makes sense :^)

Is this a known issue in AW?
Jon
February 26,
I guess this is about AW.HTTP.Request class and its subclasses (AW.CSV.Table, AW.XML.Table)?

AW.HTTP.Request does not specify the content length, this is done automatically by the XMLHttpRequest object. Are you saying that we should add CRLF at the end of the parameters string?

Do you know which programs actually break due to this feature?
Alex (ActiveWidgets)
February 27,
Here is the code that I am using (with workaround included):
var req = new AW.HTTP.Request;
                theDate = new Date(); 
                req.setURL(URL);			  
                req.setParameter("IDs", IDarr);      
                req.setRequestMethod("POST");  // use 'POST' request method
                req.setRequestHeader("User-Agent", "Some_Name"); 
                req.request();


Basically when the request is sent via XMLHttpRequest the User-Agent is set to whatever browser you are using and it sets the content-length header correctly.

We are using are own custom web server we developed in house to do some very tricky stuff....thats where the IE bug causes problems. Our Server is told via the Content Length header to expect "X" amount of bytes but the IE bug sends the 2 extra bytes. So in our webserver code we catch that by looking at the User-Agent...if IE then Expect 2 extra bytes. This is a very common workaround in lots of software. (and thats basically why MS hasn't fixed it :^) )

So the simple workaround is to change the User-Agent to anything but IE.
Jon
February 27,
Interesting. Is this documented anywhere other in these comments?
D
February 27,
<a href="http://support.microsoft.com/kb/823099">http://support.microsoft.com/kb/823099</a>
Jon
February 28,
Oops sorry...

http://support.microsoft.com/kb/823099
Jon
February 28,

This topic is archived.

See also:


Back to support forum