- From: Osama Mazahir <OSAMAM@microsoft.com>
- Date: Thu, 21 Mar 2013 05:43:02 +0000
- To: "Adrien W. de Croy" <adrien@qbik.com>
- CC: IETF HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <B33F11E188FEAB49A7FAF38BAB08A2C001D8AF51@TK5EX14MBXW602.wingroup.windeploy.ntde>
I suspect some IIS plugin generated a malformed response. You could try posting your question to www.iis.net<http://www.iis.net>. From: Adrien W. de Croy [mailto:adrien@qbik.com] Sent: Sunday, March 17, 2013 2:56 PM To: Osama Mazahir Cc: IETF HTTP Working Group Subject: Re: Dealing with bad server chunking FIN from server. Regards Adrien ------ Original Message ------ From: "Osama Mazahir" <OSAMAM@microsoft.com<mailto:OSAMAM@microsoft.com>> To: "Adrien W. de Croy" <adrien@qbik.com<mailto:adrien@qbik.com>> Cc: "IETF HTTP Working Group" <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>> Sent: 16/03/2013 6:55:37 a.m. Subject: RE: Dealing with bad server chunking >> WinGate detects this as an abortive close Are you seeing a TCP FIN or RST? From: Adrien W. de Croy [mailto:adrien@qbik.com<mailto:adrien@qbik.com>] Sent: Thursday, March 14, 2013 9:45 PM To: IETF HTTP Working Group Subject: Dealing with bad server chunking Hi all we have recently had issues with a site where the server sends chunked responses back but closes the TCP connection prior to sending any 0 chunk (in fact we never see a packet with this). WinGate detects this as an abortive close, and if there were any filters processing the stream, they are reset, and the data may not go to the client. However, client browsers typically "forgive" this transgression without any sort of warning. Should we be making more forceful suggestions about this in the specs? It seems slightly dangerous that a browser would consider content perfectly fine to use when the chunked transfer was aborted. Is this actually a security issue, or should we be more tolerant? The customer of course just wants to be able to go to the page, and chances of getting it fixed seem slim. Is this also a known bug in IIS6.0? Regards Adrien GET / HTTP/1.1 Host: www.smemsc.org<http://www.smemsc.org> Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Connection: Keep-Alive HTTP/1.1 200 OK Connection: close Date: Fri, 15 Mar 2013 04:29:44 GMT Server: Microsoft-IIS/6.0 x-server: sjl03 X-AspNet-Version: 2.0.50727 Transfer-Encoding: chunked Cache-Control: private Content-Type: text/html; charset=utf-8 1f9 <html><head> <title></title></head> <!-- Redirection Services SJL01WRED03 H1 --> <frameset rows='100%, *' frameborder=no framespacing=0 border=0> <frame src="http://www.smemsc.comcastbiz.net" name=mainwindow frameborder=no framespacing=0 marginheight=0 marginwidth=0></frame> </frameset> <noframes> <h2>Your browser does not support frames. We recommend upgrading your browser.</h2><br><br> <center>Click <a href="http://www.smemsc.comcastbiz.net">here</a<http://www.smemsc.comcastbiz.net%22%3ehere%3c/a>> to enter the site.</center> </noframes></html>
Received on Thursday, 21 March 2013 05:43:50 UTC