Cannot parse HTTP response; Status line contains no spaces. Data: #123 0

[Clint Irving]

Whenever Fiddler is capturing traffic in my web application, about 20% of all types of requests (GET/POST/PUT/DELETE) result in the following:

 

1. Result: 500

[Fiddler] Response Header parsing failed.

This can be caused by an illegal HTTP response earlier on this reused server socket-- for instance, a HTTP/304 response which illegally contains a body.

Response Data:

<plaintext>

30 0D 0A 0D 0A 0....

2. Protocol Violation Report - "Cannot parse HTTP response; Status line contains no spaces. Data: #123 0"

3. A second request that succeeds (in version 2.4.4.4 this request seemed to follow about 60 seconds later, in 2.4.4.5 this seems to happen immediately after the first request).  The delay caused in version 2.4.4.4 was an issue for my app, requests were always reaching the sever, responses were delayed in Fiddler - however, in version 2.4.4.5 this is more of a minor inconvenience when looking through Fiddler traces.  The two requests made to the server are identical.

Some details on the requests I'm making:

1. Client application is built on Backbone.  The sync methods initiate the calls to the server.

2. The server is built on ServiceStack and features a simple REST endpoint.

 

Any thoughts on what might be going wrong here?  Any suggestions on further details that would be useful in diagnosing this?

Thanks!

[EricLaw]

This message means exactly what it says: the server returned something which wasn't a valid HTTP response. The typical problem, as noted by the error message, is that this (previously used) connection is being reused for a subsequent request, and the previous response on the connection was malformed and returned more data than it should have.

 

That "excess" data is parsed as the beginning of the subsequent HTTP response body and as a consequence the error message is shown.

 

Can you share a SAZ capture of this scenario? That might help demonstrate what was wrong with the original response that caused it to return excess data. From the look of it, it appears that maybe the server tried to use HTTP Chunked Encoding but incorrectly returned a second terminal (0-byte) chunk.

 

thanks!