Incorrect ServerDoneResponse value when streaming is enabled

3 posts, 0 answers
  1. Sally
    Sally avatar
    2 posts
    Member since:
    Apr 2016

    Posted 10 Apr 2016 Link to this post

    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.
  2. Sally
    Sally avatar
    2 posts
    Member since:
    Apr 2016

    Posted 10 Apr 2016 in reply to Sally Link to this post

    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.
  3. Tsviatko Yovtchev
    Tsviatko Yovtchev avatar
    549 posts

    Posted 15 Apr 2016 Link to this post


    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?

    Tsviatko Yovtchev
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top