#326 HTTP Capture : No primary URI / Timer set with some browser


Environnment : Windows XP SP2
Internet Explorer : 6.0.2800.1106.xpsp2.0530301-1526
Patchs : SP1; Q867801; Q903235

Capture mode : Gateway (Local) / No proxy used / Page
timers is on

1) Script Record via Script Modeler->Capture->Record

2) In the HTP result file, there is no URI with the
PRIMARY keyword and timers

If I do the same actions by using Internet Explorer 5.5
or Firefox, no problem. I can obtain PRIMARY
URI et timers.

After investigating the problem, I realize that
browsers send different HTTP headers request and that
the value of field "Accept" in HTTP header seems to be
very important for HTTP recorder module in order to

With IE 6.0, the value of ACCEPT is always the
following ("*/*") for all kinds of URI (primary
[servlet], normal [images]) and so, the recorder can't
find the PRIMARY URI and position the TIMERS.

Moreover, when you use the "BView" add-on to replay
the capture, no screen is displayed

Is is possible for recorder module (and probably
"BWiew" add-on) to use another HTTP header field to
determine PRIMARY URI ("Referer" could be a good
candidate) without depending on "Accept" field whom
value depends on your favourite browser ?


  • Daniel Sutcliffe

    • assigned_to: nobody --> dansut
    • status: open --> open-accepted
  • Daniel Sutcliffe

    Logged In: YES
    Originator: NO

    The code does use the Accept header to decide whether a
    request is PRIMARY or not - a request with only '*/*' in
    the 'Accept:' header is seen as not a PRIMARY request,
    everything else is a PRIMARY.

    This theory obviously breaks whenever a HTTP client
    decides to do something different - the content of the
    'Accept:' header is not a great thing to base the
    decision on. However, the PRIMARY keyword has no real
    functional meaning - the only potential problem is if
    you want to rely on the optional automatically recorded
    'Page Timers' which will be in the wrong place.

    The 'Referer:' header would seem to be a good choice to
    base the decision on - but the Referer of the 2nd primary
    is the same as that of secondaries to the 1st primary,
    etc. Maybe the only ways to truly identify primary
    requests are:
    - actually see the user clicks and only label the
    requests that come from these as being.
    - post process the recording and label as a primary just
    the requests that are mentioned in a Referer field -
    but this means you'd miss primary pages with no sub

    Neither of these are ideal or practical solutions so it
    will probably be left as it is until a better idea can
    be thought of, or a strong reason for changing it

    The comments about BView do not belong in this bug
    report - BView is an add-on to the OpenSTA toolset and
    not part of the project, plus I'm not sure how the
    problem is related.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks