The Network Inspector is Opera Dragonfly’s HTTP dashboard. It provides an overview of all HTTP requests – for resources such as images, scripts, and stylesheets – initiated by the primary webpage (primary HTTP request).
The first tab of the Network Inspector is the Network log. HTTP requests can be displayed as either a waterfall graph – a timeline listing all requests in the order in which they were sent – or as a tabular data grid.
The data view table can be reordered by clicking on the various column headers. The type of columns that are displayed can be customised through the grid's context menu, and reset back to the default set of Method, Status, MIME, Size, Waiting, Duration and Graph.
The network log can be cleared – removing any existing entries showing up in the log – and updating of the log can be paused. The latter is particularly useful if you're interested in analysing the initial page-load of a document that also fires XHR requests after all primary content has been loaded.
In both grid and data view each requested URI is preceded by an icon, which provides a visual cue about the type of resource that was requested:
|markup (HTML, XHTML, …)|
By default, requests for all types of resources are shown in the log. The type filter lets you narrow down the view to certain types of Resources – Markup, Stylesheets, Scripts, Images, Other file types, or any requests made via an XMLHttpRequest. The type filters can be combined (for instance, to just show Markup and Stylesheets) by toggling the relevant buttons with CTRL / CMD + click.
To get the most precise information for network activity, it's possible to further improve the log's timing accuracy by disabling all other debugging services and placing Opera Dragonfly into HTTP profiler mode.
When switching back to any of Opera Dragonfly's other tools, you will first need to re-enable these services, which may require reloading the current document.
The Network log's search functionality works across all URIs listed in the log, as well as any open details view overlay. You can move between any matches found using F3 / Shift+F3.
URIs appear truncated in the left-hand column, but hovering over each of these displays a tooltip with the fully qualified URI, including the protocol, domain, and full path to the resource. Any GET parameters present in the URI are decoded, reformatted and listed in this tooltip as well.
The graph associated with each request (both in the full waterfall graph view and the normalized small graph in the grid view) uses specific colors to represents the different phases of resource retrieval. These fall into categories such as scheduling (grey), sending (red), waiting (blue), receiving (green) and processing (grey). Occasionally, requests have to be retried or they are aborted – these actions, and the related phases, are show in yellow. Hovering over a graph opens a tooltip with a more detailed breakdown of the various retrieval phases.
Clicking on a URI opens a detailed look at the request in a resizable overlay. This view shows the raw headers and body of both the request and response. Long lines are wrapped by default. For POST requests, you can further switch the details view to "Parsed mode", which reformats form-encoded requests as name-value pairs.
In a similar way to command-line tools such as
curl, the Make Request tab allows you to manually send custom HTTP request to a specific URI and to inspect the HTTP response.
Opera Dragonfly makes it easy to precisely tailor an HTTP request by specifying the individual HTTP headers. Start by entering the URI for your request in the URL field. This immediately modifies the Request body to make a standard GET request to this URI, using Opera's default HTTP headers. You can manually modify the Request body further by simply editing the generated request. Once it has been sent, you will see the response from the server, including the raw response headers. If the response's body contained contained text, this will be displayed in full; binary data (for instance when making a request for a
png image) on the other hand will appear truncated.
The third panel provides options for fine-tuning the browser behavior with regards to HTTP requests.
When testing HTTP requests, it is often important to disable all sources of caching, forcing Opera to request and load all resources from the server.
In cases where a site does content negotiation – or, more commonly, serves different content to different user agents – it is sometimes necessary to spoof headers to appear as another HTTP client, such as a bot or a mobile browser, in order to verify and debug the server's response. With global header overrides, Opera's standard request headers can be overriden (to change a particular aspect of the request) or expanded (to include additional headers that aren't normally sent).
The available presets include the default headers (including the
User-Agent) of a few common mobile, tablet and desktop browsers. If the particular browser you want to spoof is not available in the list of presets, or if you want to just add or override one specific header, you can further modify the headers in the provided text field. Once you're satisfied with the set of headers that will be sent, make sure to Save your selection.
Note that once an override has been set, it takes effect in the current debugging context for as long as Opera Dragonfly is open, even when switching to other tools like the Console or the Document panel.