Incorrect ServerDoneResponse value when streaming is enabled

[Sally]

I am using Fiddler to analyze XHR calls an Angular web app makes. In one particular case, the HTTP request to the server completes in one second, and in response to the XHR.onload event the client code performs a long-running operation (that takes, say, 10 seconds). When streaming is not enabled, Fiddler correctly reports a ServerDoneResponse time as being one second after FiddlerBeginRequest. When streaming is enabled, however, ServerDoneResponse is 11 seconds after FiddlerBeginRequest, i.e., Fiddler is including the time the client takes in response to XHR.onload. Is this a bug in Fiddler, or is this somehow expected behavior? For what it's worth, Chrome's dev tools network tab seems to have the same problem, in that it includes the time taken in onload when reporting how long the request took. Interestingly enough, Chrome's timeline tab does not have this problem - it correctly reports how long the request took.

[Sally]

Edit: so after experimenting a bit, it does not seem like the issue is caused by onload not returning until 10 seconds - I think it has something to do with having multiple requests fired off near-simultaneously. But the stats displayed by Fiddler definitely seem odd: the 10 second gap is actually between GotResponseHeaders and ServerDoneResponse. IE's dev tool reports the 10 seconds being TTFB ("The time taken to send the request and receive the first response from the server."). And again, I do not see this behavior when buffering instead of streaming.

[Tsviatko Yovtchev]

Hi,

What is in the Log tab when that happens? Is there any difference between what's logged in streaming and buffering mode that could explain what happens?

Regards,
Tsviatko Yovtchev
Telerik