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

[duominike]

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 1.5.0.4, 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
choose PRIMARY URI.

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]

Logged In: YES
user_id=19748
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
content.

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
arrives.

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.