HTTP Monitor

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(Firebug Integration)
(Experience)
Line 73: Line 73:
* Firebug team is now maintaining yet another project (HTTPM).
* Firebug team is now maintaining yet another project (HTTPM).
* Implementation of the ''remoting'' support requires improved Firebug infrastructure (e.g. new ''connection'' object). Similarly to the existing one, new API will be probably copied into HTTPM.
* Implementation of the ''remoting'' support requires improved Firebug infrastructure (e.g. new ''connection'' object). Similarly to the existing one, new API will be probably copied into HTTPM.
 +
* NetExport needs to be refactored (and partially included in HTTPM?)

Revision as of 14:11, 31 May 2012

This page is related to HTTP Monitor tool. This tool (or a component) is intended to track HTTP activity of given local or remote browser tab and display results to the user.

Contents

Resources


Download

Working HTTP Monitor (Firefox extension) is available. See also the instructions about how to use it. The goal of the HTTP Monitor component is to be shared between Firebug (an extension) and Firefox (built-in tool).

Architecture

Core architecture is based on the Net Panel and adapted to also support remote HTTP tracking.

Http-monitor-basic-architecture.png


Local Network Event Flow

This sequence diagram describes local monitoring scenario where the user tracks a browser tab on local browser.

Http-monitor-local-net-event-flow.png

  • HTTP Observer Observes HTTP traffic of the selected tab and sends every event to NetProgress object.
  • NetProgress object processes incoming HTTP event and produces a File object that represents the HTTP request. It uses an existing File object if there is already one created for the request. The File is further passed to Net Panel
  • NetPanel stores the file in a queue. Files in the queue are processed and rendered asynchronously on a timeout.


Remote Network Event Flow

This sequence diagram describes remote monitoring scenario where the user tracks a browser tab on remote browser. The flow shows how HTTP events are transported from the server to the client.

Http-monitor-remote-net-event-flow.png

  • HTTP Observer running on the server side send every HTTP event to the NetProgress instance (also on the server side)
  • NetProgress object processes incoming HTTP event and produces a File object (or uses an existing one) that represents the HTTP request. The File is further passed to NetworkMonitorActor
  • NetworkMonitorActor stores the file in a queue that is processed asynchronously on a timeout and send in chunks (more files at once) over TCP/IP to the client.
  • Connection object on the client side receives a packet and passes it to a Protocol object.
  • Protocol object understands structure of the packet and passes it further to a RemoteProxy object.
  • RemoteProxy gets all files in the packet and passes it further to the NetPanel object.
  • NetPanel stores the file in a queue. Files in the queue are processed and rendered asynchronously on a timeout.


Firebug Integration

Firebug integration is currently under development in httpmonitor Firebug branch.


There are currently two objects in Firebug that are derived from objects coming from HTTPM.

Firebug-integration-1.png

  • Firebug:NetMonitor
    • Overrides onLoadDocument to customize context initialization and use Firebug's context object.
    • Implements Firebug activation
    • Implements Break on XHR
  • Firebug:NetPanel
    • Custom context menu actions
    • Different way how to update Net panel XUL UI (toolbar buttons)
    • Also, custom activation and break on XHR support


Experience

This paragraph summarizes some experience collected when working on HTTPM. Following should be discussed and proper decision taken.

  • Maintaining code running in more environments is difficult.
  • There is duplicated code (e.g. the XUL interface, Lib functions and various parts of Firebug infrastructure).
  • HTTPM is embedded in Firebug as GIT Submodule. Feedback collected so far is rather against using submodules. Not sure if manual syncing is even an option.
  • Firebug is going to loose Net panel translations. It's probably necessary to get them for HTTPM again (or convert existing firebug.properties file).
  • Code in HTTPM must be often more generic since it's implementation can be different (break on next, initialization, etc.)
  • The future is uncertain (not sure whether the UI will be actually shared).
  • Firebug team is now maintaining yet another project (HTTPM).
  • Implementation of the remoting support requires improved Firebug infrastructure (e.g. new connection object). Similarly to the existing one, new API will be probably copied into HTTPM.
  • NetExport needs to be refactored (and partially included in HTTPM?)
Personal tools