With bug 866431, the memory usage of ArrayBuffer XHR requests was reduced by reading directly into a growing ArrayBuffer. We can do even better by trusting Content-Length in the header and using that as the initial allocation size, avoiding realloc fragmentation. Using just Content-Length would be a big win, because it's unlikely that ArrayBuffer-XHR content will be served with gzip encoding. But it might be, and there's no good way to handle that; I'd suggest introducing a new X-Decoded-Length header that we'll honor if present for that case.

Simple patch. Use Content-Length on ArrayBuffer loads if it's specified, up to a max of 1GB. Also adds a missing reset() to ResetResponse(), which is a bug currently (if the arraybuffer XHR is aborted without the response being read, a subsequent load would keep appending right now).

Comment on attachment 749648 [details] [diff] [review] use Content-Length, and fix ResetResponse r=me. We'll need at least the reset() bits on Aurora, right?

Yeah, we'll need the reset bits on Aurora, but should just take the whole thing.

(In reply to Boris Zbarsky (:bz) from comment #2) > Comment on attachment 749648 [details] [diff] [review] > use Content-Length, and fix ResetResponse > > r=me. > > We'll need at least the reset() bits on Aurora, right? Bug 866431 only landed on 24, so what & why do we need something for Aurora here?

Ah, I thought it had landed on 23. Vlad, do we need anything on Aurora here, or are we all good there?

Huh, I thought it landed on 23 also. In that case, nothing needed!