You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Triaging Networking Bugs
Darin Fisher / darin at meer dot net
May. 15, 2003
Ok, so you are interested in helping us triage networking bugs. Excellent! Here's some things you should know...
  • File bugs in the right component
    Meet the components... 
     
  Networking          - general networking bugs go here (including DNS bugs)
  Networking: Cache   - cache specific bugs
  Networking: File    - file specific bugs
  Networking: FTP     - ftp specific bugs
  Networking: HTTP    - http and https specific bugs (including http proxy and ssl tunnel)

  • Use the status whiteboard tags
    These tags help the developers and other triagers quickly understand what kind of bug they are looking at. 

    
  [DUPEME]            - bug is likely a duplicate (mention possible duplicate reports in comments)
  [http/1.1]          - bug has to do with HTTP/1.1 spec compliance
  [pipelining]        - bug only occurs when pipelining is enabled  
  [proxy]             - bug has to do with proxy servers
  [digest-auth]       - bug has to do with digest authentication
  [ntlm-auth]         - bug has to do with NTLM authentication
  [dns]               - bug has to do with DNS problems
    run queries: [DUPEME] [http/1.1] [pipelining] [proxy] [digest-auth] [ntlm-auth] [dns]

  • If the bug reports a problem in an older build, ask the reporter to try a more recent build
    This is pretty obvious, but often times a bug report will sit around with comments about a problem that has been fixed already.

  • If the problem is not obvious, ask the reporter to capture a network log
    See for example the HTTP Debugging Guide A problem can sometimes be diagnosed in a matter of seconds when there is a log available. NSRP logs as well as tcpdumps can each be extremely valuable.

  • Check for commonly filed bugs
    When triaging be sure to keep in mind the list of most frequently duped bug reports. Check the most frequently reported bugs and the most frequently duplicated bugs.

  • Be careful when marking bugs as duplicates
    Just because the symptoms of two bugs appear similar, it does not mean that the bugs have the same root cause. Sometimes distinct problems can share the same symptoms. For example, consider a bug report that says "Mozilla shows an empty page." There could any number of explanations for such a problem. Sometimes it requires a knowledgable developer or experienced triager to determine that too bugs are indeed caused by the same problem. Invalid duplicates cause valid bug reports to be lost, so be extra careful when you resolve a bug as a duplicate. If you are at all uncertain, it is better to simply flag the bug report with [DUPEME] in the status whiteboard field and explain what the possible duplicate bug report might be.