0

When you do a XMLHttpRequest, the data is often compressed. Looking at the Content-Length header 

xhr.getResponseHeader("Content-Length");

gives you the number of octets in the response body, to which you could add an approximation of the header by sizing the response headers.

But: How do you find the number of (compressed) bytes actually transferred? (in Firefox, if this is only possible in a browser-specific way.)

In the screenshot below, you see a difference for several files: different sizes transferred than received

The following should all be equal to this

  • the number of bytes read from the socket
  • the file size in the squid log
  • the number of application-layer octets sent over the network in response to the request
Community
  • 1
  • 1
serv-inc
  • 35,772
  • 9
  • 166
  • 188
  • 1
    Hm, that's not the number of octets in the response but the number of octets in the *response body*. Important difference. I take it you want the number of octets over the entire message? – DaSourcerer Mar 06 '16 at 15:07
  • @DaSourcerer: exactly. Thank you. – serv-inc Mar 06 '16 at 18:09
  • @DaSourcerer: and if it is compressed, the number of compressed octets – serv-inc Mar 07 '16 at 06:58
  • 1
    True. But that would still be the same as the number of octets in the response body. HTTP messages can be surprisingly agnostic towards their payload: The compression is a property of the content, not the message itself. At least as far as the `Content-Encoding` header is concerned. – DaSourcerer Mar 07 '16 at 10:10
  • @DaSourcerer: That information is again useful (and might explain why the transferred size is *bigger* than the content size for several items in the picture). To clarify: the number of application-layer octets sent over the network in response to the request. – serv-inc Mar 07 '16 at 16:56
  • 1
    There could indeed be another reason: If a server is configured to compress images as well, they could actually *increase* in size through the compression. The established algorithms for HTTP transport tend to not work that well on binary data ;) – DaSourcerer Mar 09 '16 at 17:05

2 Answers2

2

UPDATE: the performance api seems to provide this: Call as

performance.getEntries()[0]

and see the encodedBodySize (see also at MDN).

The screenshot above shows the Network Monitor. Its code seems to use the network-monitor.js file which

implements the nsIStreamListener and nsIRequestObserver interfaces. This is used within the NetworkMonitor feature to get the response body of the request.

The relevant code seems to be

  onProgress: function(request, context, progress, progressMax) {
    this.transferredSize = progress;
    // Need to forward as well to keep things like Download Manager's progress
    // bar working properly.
    this._forwardNotification(Ci.nsIProgressEventSink, "onProgress", arguments);
  },

with

  _onComplete: function NRL__onComplete(aData)
  {
    let response = {
      mimeType: "",
      text: aData || "",
    };

    response.size = response.text.length;
    response.transferredSize = this.transferredSize;

The progress event is part of neither interface. It may be from xhr, but where it came from is as of yet unclear.

serv-inc
  • 35,772
  • 9
  • 166
  • 188
1

As long as the response is text (as opposed to binary blobs), you have some good starting points here, on SO : Measure string length in bytes

Community
  • 1
  • 1
Tudor Ilisoi
  • 2,934
  • 23
  • 25
  • It seems my question was not clear enough. It is about the number of bytes *as sent*, including compression. Or did you mean that the text could be reconstituted, then recompressed? (the link talks about something similar to this with encoding) – serv-inc Mar 07 '16 at 06:59