Because extended properties require BrowserHawk to transparently interact with the browser, there are several important options to consider when testing extended properties. One such option used to tell BrowserHawk exactly which extended properties you wish to test. For example, it is more efficient to test for a dozen or so properties than it is to test for over one hundred. Therefore you use the provided methods to tell BrowserHawk which of its extended property tests to perform.
Likewise there are several different ways that BrowserHawk can communicate with the browser, as controlled by the specified RequestType. Each request type has its own advantages.
The requestType parameter controls whether BrowserHawk uses the GET or POST method to process the results of the silent client-side test page, and in the case of the GET requests, whether the results are passed in the query string or in a temporary cookie.
The requestType parameter can be set as follows:
0: Auto-select
This setting instructs BrowserHawk to choose the most appropriate requestType for you, given the content in which your page is running. If your web script is accessed via a GET request, it will use the requestType of 1 (cookie based). If the visitor has cookies disabled, however, it will sense this on-the-fly and instead use a requestType of 2 (query string based). If your page is accessed via a POST request, it uses a requestType of 3 (POST based). Using this auto-select mode is the default and recommended setting. If you are performing a check for FontsInstalled and specify "all" for the FontsToCheck property, BrowserHawk will use the POST requestType for you automatically to handle the large list of font names that may be returned.
1: Cookie based
A requestType of 1 instructs BrowserHawk to have the test results passed from the browser back to BrowserHawk via a temporary session cookie. Internally BrowserHawk then reads through this cookie collection, sets the various properties according to the values, and deletes the cookie.
If the user has session cookies disabled, or chooses not to accept the cookie (if their browser is set to prompt before accepting cookies), then BrowserHawk automatically downgrades itself on-the-fly to use requestType 2.
If performing an extended property check from a script accessed via the GET method, this requestType is highly recommended and the most efficient. This approach gives you the best of both worlds - for users with cookies enabled, the test is completely silent and transparent and there is only one small token added to the query string regardless of how many properties you are checking. Yet at the same time, if the user has disabled their cookies, BrowserHawk adjusts this for you and falls back on the query string method (requestType 2).
Advantages / Disadvantages of this requestType
Advantages:
Completely transparent and silent testing – only one very minor change is made to the query string ("bhcp=1" is added) regardless of how many tests are performed. This assumes the user's cookies are enabled
BrowserHawk internal processing of the results is very efficient
Automatically falls back to requestType 2 if the user's cookies are disabled
Disadvantages:
You cannot use this requestType from a page POSTed to – otherwise the posted data and request object will be lost.
2: Query string based
A requestType of 2 instructs BrowserHawk to have the test results passed from the browser back to BrowserHawk via the query string. Any existing information in the query string is preserved.
Unlike older versions of BrowserHawk, only the specific test results you ask for are adding to the query string. This results in minimal changes to the query string. For example, if you just ask BrowserHawk to check the version of Flash installed, only one name/value pair is added to the query string.
Unless you have a specific reason why you want the results passed in the query string, we recommend that you use a requestType of 1 for a cookie-based test instead. In the event the user has cookies disabled, BrowserHawk automatically falls back to using this requestType so you will be covered either way.
Advantages / Disadvantages of this requestType
Advantages:
You may prefer to have the results in the query string for other purposes. Please note however that the token names in the query string are subject to change in future versions of BrowserHawk. Therefore it is recommended you get the results by accessing the BrowserHawk's properties rather than reading it from the query string.
Disadvantages:
BrowserHawk adds name/value pairs to the query string for the properties you ask it to check. If you are only checking a few properties this change is minimal. For example, the URL shown in the browser after executing a test for screen resolution may become page.asp?bhsw=800&bhsh=640. If you are checking several extended properties the URL can become quite long. This will not affect how your page works in any way, but some developers prefer not to have long query strings shown in their URL.
You cannot use this requestType from a page POSTed to – otherwise the posted data and request object will be lost.
3: POST based
A requestType of 3 instructs BrowserHawk to have the test results passed from the browser back to BrowserHawk via the POST method. Any values currently being POSTed in (from a form submission, for example) are preserved.
This method is only recommended if you need to use the extended property checks from a page that is posted to, and you have no opportunity to execute the test in a page prior to the POST (for example if another web site or application is posting results to your page).
If it is possible to run the extended property test from the page displayed prior to where the post occurs, it is recommend you perform the test on a prior page. For example, perform the extended property check from the page which displays the form fields, and set the results to hidden form fields. Then in your page that does the post processing, simply get the values from the hidden form field.
Note: If you are using this requestType and the user has JavaScript disabled, BrowserHawk will not be able to POST the results to the destination script. This is because JavaScript is required to perform the post. However, BrowserHawk wisely detects if this condition occurs, and passes in all posted values via the query string as a GET request if so. Tip: With classic ASP, use 'Request("field_name")' instead of 'Request.Form("field_name")' in your scripts in conjunction with the GetExtPropertiesEx method and requestType 2. By using this technique your ASP page will pick up the value from the form automatically – regardless of whether BrowserHawk winds up POSTing it in or passing it in via a GET request if JavaScript is disabled.
Advantages and Disadvantages of this requestType
Advantages:
All of the Request object, including Request.Form, is preserved. This makes it safe to use the extended property checks from scripts which perform POST processing.
Since the results of the test are POSTed in, BrowserHawk does not add to or modify the query string in any way. This means that your original URL for the page remains.
Disadvantages:
If the page containing the call to the extended property check is accessed via a POST (such as the target of a form submission), the user may receive a message from the browser saying that the page has expired if they press their back button.
If the page containing the extended property check is accessed via a GET instead of a POST, the user will be bounced right back to the current page. This effectively renders the back button useless. You can however use the ExtPropBackDelay (ActiveX) or BackDelay (.NET) property to add enough of a delay to allow users to press the back button a second time to break out of the loop.
See Also:
GetExtPropertiesEx Method (ActiveX)
SetExtProperties Method (ActiveX)