Include bytes sent/received in HTTP requests for replays

[bruno-garcia]

The goal here is to get on the Replay blob request_body_size and response_body_size so we can understand how large these are.
We'll need to set some limits so it can also help answer the question: "Why don't I see my request body" or "why is it truncated"?

Additionally, it'll help us get a distribution of size and decide what these limits should be.

Note that Mobile SDKs add to breadcrumb.data the keys request_body_size and response_body_size to all breadcrumbs. This isn't on the develop docs it seems but possibly good value to breadcrumbs XHR/fetch on JS too outside of Replay

[bruno-garcia]

FYI @krystofwoldrich outside of replays this would affect React Native and bring in on par to the other mobile SDKs if we're aligning.

[mydea]

So just to clarify, we'll add this for all breadcrumbs, not just in replay itself. We'll add:

• request_body_size
• response_body_size

Which we get the same way as for replay recording length:

new TextEncoder().encode(recordingData).length

(Which is not supported in IE11, so we'll just not have this data there).

Final question: Should we do this for all requests/responses, or just for e.g. JSON? For responses we can probably look at content-type headers, for requests not so much (we can't access them).

I would propose one of these options, for simplicity:

1. Only capture it if we detect it to be a JSON string (starts with { and ends with }, or starts with [ and ends with ]), or form data (TBD how to detect this)
2. Always capture it from the text representation (not 100% sure but may be incorrect for non-text media types, I guess)

[krystofwoldrich]

@bruno-garcia Thanks
@mydea RN doesn't have TextEncoder either. If possible let's use the TextEncoderInternal abstraction so we can supply our own.

[billyvg]

Final question: Should we do this for all requests/responses, or just for e.g. JSON? For responses we can probably look at content-type headers, for requests not so much (we can't access them).

Shouldn't we be able to access the request headers (at least for fetch?)

I would propose one of these options, for simplicity:

1. Only capture it if we detect it to be a JSON string (starts with { and ends with }, or starts with [ and ends with ]), or form data (TBD how to detect this)
2. Always capture it from the text representation (not 100% sure but may be incorrect for non-text media types, I guess)

I'd lean towards #2, but we should do some testing to see how inaccurate this can be.

[dprevost-LMI]

bytes or kb, bytes I assume?