Network requests and their responses are recorded by default.
Disabling network request recording
You can disable network request recording.
- Open the Bird Eats Bug browser extension settings, by either:
- Opening the extension popup and clicking on the settings cog in the upper right corner.
- Going to the
Manage Extensionspage on
chrome://extensions/and then clicking
- Toggle the
Network requestsswitch in the
Data recording optionssection.
Pass a custom
recordedEventTypes option when setting the SDK's option in your code integration:
/* ...other event types */
network: false /* disable recording of network requests */,
Network request recording is inherently imperfect due to reasons layed out below. Necessary trade-offs result in the limitations described below:
- Response bodies are only recorded if their payload size is not more than 1MB.
- Response bodies are only recorded if the Content-Type header includes the word
text. Bird does not attempt to capture binary information like images, videos, or files like PDFs.
- Response recording does not work with Flutter web apps at the moment.
- Response recording does not work for requests issued by workers.
- Responses might not be recorded if the response came in right before the client loaded a new page, e.g. due to a HTML form submission, or a server-side redirect.
Websocket connections are not being recorded at the moment.
Complexities of network recording
Network request recording has more caveats than other recorded data types. There are two reasons for that:
- Frequency and size of network requests
- Browser APIs allowing to access network request information
Frequency and size of network requests
Pages can execute hundreds or even thousands of network requests per minute. They can contain large payloads. Recording all data flowing over the browser’s network can easily accumulate hundreds of Megabytes of data in short time periods. Therefore we have to put reasonable limits in place for the capture of network request recording, frequency and size of network events, in order to avoid these potential problems:
- Slowdowns of the browser / operating system / recorded pages
- Running into storage limits
- Painfully slow session uploads
- An increased likelihood of Bird or the recorded page crashing
Browser APIs allowing to access network request information
WebRequest browser extension API does not allow the capture of network request responses (at least in Chromium based browsers). It's also only available for browser extensions and hence wouldn't work for our SDK.
Since response information is likely to contain crucial information for debugging, Bird additionally instruments
XMLHttpRequest, which is the approach taken by client-side monitoring tools such as Sentry.
Just using the
XMLHttpRequest monkey-patching does not allow to record requests issued by the browser (on page load, redirect, form submission,…). For this reason, Bird employs the
WebRequest extension API for all request types except for
XMLHttpRequest, and instead records these by instrumenting
XMLHttpRequest. Due to the different data sources, the timing / order of requests can potentially slightly differ from the actual timing / order. Recording all request types with the
WebRequest API, and enriching it with the response body information is difficult, because there's no ID that can be cross-referenced across these different methods.