HttpWebRequest and Transfer-Encoding: chunked problem

Question

 
0 
 
 
HttpWebRequest is used to download files from ASP.NET site with basic authentication. Everything works fine in much cases. But some proxies make answer chunked and HttpWebRequest.GetResponse() throws an exception if answer with 401 code is chunked. The exception is:
System.Net.WebException: The server committed a protocol violation.
Section=ResponseStatusLine at System.Net.HttpWebRequest.GetResponse()
Trace of answer is:
"HTTP/1.1 401 Authorization Required\r\nDate: Fri, 26 Jun 2009 04:45:18 GMT\r\nServer: Microsoft-IIS/6.0\r\nX-Powered-By: ASP.NET\r\nX-AspNet-Version: 2.0.50727\r\nWWW-Authenticate: Basic realm=\"iis-server\"\r\nCache-Control: private\r\nContent-Type: text/html; charset=iso-8859-1\r\nVia: 1.1 server\r\nKeep-Alive: timeout=15, max=100\r\nConnection: Keep-Alive\r\nTransfer-Encoding: chunked\r\nContent-Language: en\r\n\r\n0\r\n\r\n0\r\n\r\n"
I made test and found out that "Transfer-Encoding: chunked" is the only one reason of exception. Is this bug of .NET Framework 2.0 or there any RFC says that 401 answer shouldn't be chunked?

Answer 1

im not sure about the RFC but in my experience i have never seen a response body with a 410 response. a 401 response means that the server requires authentication and the headers should just include the types of authentication that the server accepts (BASIC, NTLM etc). it *can* include other headers like keep-alive and timeout, but it has no need for a response body since the response is never displayed (eg in the web browser), it is just used to inform the client that it must resend the request with authentication credentials.

so one possibility is that the web server is sending back a buggy response, ie it should not send back the Chunked encoding header at all.

also i notice that the response above has \r\n\r\n0\r\n\r\n0\r\n\r\n at the end. chunked encoding looks for a single terminating \r\n\r\n0\r\n\r\n, which indicates the end of the http - this response seems to have 2 terminating zero's which would again suggest that the web server has in this case sent back a buggy response. i would simply handle the exception, and in the handler, parse the response again yourself.