Network Recording

Network requests and their responses are recorded by default.

Disabling network request recording

You can disable network request recording.

Browser extension

1. 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 Extensions page on chrome://extensions/ and then clicking Details -> Extension options.
2. Toggle the Network requests switch in the Data recording options section.

SDK

Pass a custom recordedEventTypes option when setting the SDK's option in your code integration:

window.birdeatsbug.setOptions({
	/*...otherOptions, */
	recordedEventTypes: {
		/* ...other event types */
		network: false /* disable recording of network requests */,
	},
})

Recording limitations

Network request recording is inherently imperfect due to reasons layed out below. Necessary trade-offs result in the limitations described below:

Response bodies

• 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 json or 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.

Websockets

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

The 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 fetch and XMLHttpRequest, which is the approach taken by client-side monitoring tools such as Sentry.

Just using the fetch and 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 fetch and XMLHttpRequest, and instead records these by instrumenting fetch and 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.