デバイスとターゲットを作成する方法
HTTP/S 監視では、単一の URL で可用性、パフォーマンス、適切なコンテンツ、およびエラーがチェックされます。 一般的な種類の要求、Cookie、フォーム送信、カスタムヘッダー、パスワードで保護されたサイト(基本的なHTTP / S認証およびCookie/スクリプト承認メカニズム)、およびタイムアウトしきい値をすべてサポートしています。
HTTP/S 監視では、セキュリティ証明書の検証、認証局のチェック、および証明書の有効期限チェックの実行が行われます。 証明書の有効期限が近づいたときにリマインダーを送信するように構成できます。
HTTP(S) 要求パラメーターをコンテキスト パラメーター に変換して、たとえば、監視デバイス内の別の要求の応答から取得した値を渡すことができます。 URL、ヘッダー、要求本文、および準備/投稿スクリプトのコンテキスト パラメーターを設定できます。 詳細については、「 HTTP(S) 要求でコンテキスト パラメータを使用する方法」を参照してください。
一括インポート
ワンクリックで多数のデバイスの監視を作成するには、[監視の種類の選択] ページで HTTP/S 監視の種類に提供されている [一括インポート] オプションを選択します。 詳細については、 一括インポート |ウェブページの監視、HTTP/S、およびPING/ICMPデバイスの 記事 ウィキの記事。
要求の構成
URL
Enter the URL of the page you wish to perform the task on. It should be formatted as such: www.example.com. You can turn on a visually friendly input mode by clicking the Detailed switcher on the top of the section.
SSL/Certificate Check
Secure Socket Layer SSL Certificate Check is a standard aspect of HTTP(S) tests.
The following additional options are available:
- Authority: verifies whether a certificate chain contains a root certificate that is trusted, or not trusted.
- Common Name (CN): validates that an address you navigate to matches the address certificate the address was signed to.
- Date: verifies the certificate expiration date.
- Revocation: validates that the certificate’s chain of trust doesn’t contain a revoked certificate.
- Usage: verifies a certificate chain for the improper use of an intermediate certificate.
- Expiration Reminder in Days: a reminder that notifies (as an error) about certificate expiration.
- Client Certificate: client certificate name.
要求の種類
In the Request Type field, you can select one of the most-commonly-used HTTP methods to send monitoring requests to a web page. If you need to send a payload with HTTP requests, provide it in the corresponding field (see the Request Body chapter for details). The payload can be specified and sent with all types of requests except Trace (RFC2616).
「ターゲット ホスト名または IP アドレス」も参照してください。
時間検証のしきい値 (秒)
システムが Web ページからの応答を待機してからタスクを終了してエラーを返すまでの最大秒数を入力します。
最大タイムアウト値は 70 秒に制限されています。 しきい値が設定されていない場合は、既定の 70 秒のタイムアウトがタスクに適用されます。
URL リダイレクト
If the Follow Redirects option is set to Yes, the system will follow the path of the URL that is sent with the 301 response and consider each redirect as a separate HTTP request. It enables you to follow the full redirect chain (all the links the request is redirected through) in the test results, including response times both for the initial URL and subsequent responses.
We recommend that you leave the Follow Redirects option activated if you need to test not only the initial URL, but all the URLs in the chain. For example, it can be useful to perform an SSL certificate check for each URL in a redirect chain.
In cases where you want to test an initial URL only, disable the Follow Redirects option.
Note that a default redirection limit is set at 10 redirects. If you want the system to execute a particular number of redirects (less than 10), you can specify the number of URLs you want to test in your redirect chain in the Prepare Script field:
string url; url = "http://wtatour.com/"; currentTask.TaskMaxRedirectAttempts = N;
Where N is the number of redirect locations we want to follow. To follow no redirects, simply set the number of redirect locations to 0.
コンテンツの検証
コンテンツ検証キーワードは、特定のテキストまたは要素が Web ページの HTML ソースコード内に存在することを確認するために使用されます。Webページのコンテンツ検証に適したキーワードを選択するには、Webページのソースコードにアクセスし、コンテンツを一意に表すキーワードまたはフレーズを選択します。ブラウザーで Web ページにテキストが表示されても、HTML ソース コードで見つからない場合、テキストは生の HTML に直接含まれておらず、JavaScript によって動的に生成されるか、外部 API から読み込まれるか、IFrames に埋め込まれている可能性があります。Web ページのコンテンツ検証でこのタイプのテキストを使用する場合は、 単一の Web ページ デバイスを構成して、実際のブラウザー ウィンドウでパフォーマンス監視を設定します。
HTML ソースにアクセスするには
ツールまたはスクリプトを使用して、ターゲット Web ページの HTML ソースをフェッチします。たとえば、ブラウザでWebページを開き、ページ上の任意の場所を右クリックして、[ページソースの表示]を選択します。
キーワード フィールドには複数の文字列を入力できます。 値は論理式で区切ることができます。
{[("keyword1"&"keyword2")|!"keyword3"]}
ここで:
{[ – キーワード式の開始;
]} – キーワード式の終了;
() – 括弧のグループ化;
& – 論理AND;
|– 論理OR;
!- 論理的ではない;
“string” – キーワード。
正常なキーワード式には、次のように開始および終了の角かっこを含める必要があります。
{["keyword"]}
認可
The HTTP authentication protocol is used to allow users to access content on some websites.
The following authentication schemes are available:
- Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
- Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
- NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.
Once provided, login credentials will be passed along with the request header to the web server.
- Username: contains a username for HTTP/S authentication.
- User Password: contains a password for HTTP/S authentication.
Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.
Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.
ヘッダー
このオプションを使用すると、カスタム ヘッダーを追加できます。 たとえば、コンテンツタイプヘッダーで、送信されるデータの MIME タイプと要求を定義できます。
Content-Type: text/html
要求に Content-Type ヘッダーが指定されていない場合、要求は既定のコンテンツ タイプ アプリケーション/x-www-form-urlencodedで送信されます。
The default User-Agent header is set to:
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) DMBrowser/2.1 (SV)
However, the user-agent string can be replaced with any other string. To do this, add a custom header with the name “user-agent” and the specific value needed.
要求本文
Dotcom-Monitor allows you to send payloads in HTTP(S) requests (except Trace requests). The content within the HTTP request body can be sent as “raw” data (JSON, XML, etc.) or static name-value collection (Form Data).
To work with a name-value collection, you can turn on the detailed input mode by using the Detailed switcher on the top of the section and provide request parameter names and values in the corresponding field.
To send “raw” data along with the request, such as a JSON object, enter your JSON payload in the input field. You can also dynamically change the request body. For example, if you need to send the current date and time as a part of your POST request or pass the current session ID in JSON payload to a remote server. Dotcom-Monitor enables dynamically changing HTTP request payload by using the Razor syntax and data masks.
-
Example. Dynamic JSON Body for HTTP Post Requests
To better understand how Dynamic JSON body works in the HTTP request, let’s have a look at the following example. Suppose we need to submit an order on a website and the submission transaction includes three basic steps executed sequentially:
- Login
- Check-in
- Order Submission
To set up a test with these steps executed sequentially, we need to create three HTTP tasks within one monitoring device (or load test, if load testing is taking place).
Let’s assume that we need to send the current time and a unique GUID in the JSON with the HTTP request to check in with the application. Also, to submit an order, a user session ID generated upon login and an order time is required by the application.
To implement this test, we first need to configure a login request with basic authentication parameters to the web application web server. Next, we need to configure an HTTP request to pass the actual check-in time and unique GUID along with a JSON body. For this example, we will enter the following string using the Razor syntax in the JSON body:
{ "CheckInTime": "@Model["CurrentTime"]", "GenGuid": "@Model["Guid"]" }Where @Model[“<Parameter Name>”] references a necessary context parameter name in the Razor expression.
We must declare the context parameters and specify how the Post Data should be processed in the Prepare Script field:
context.Guid = Guid.NewGuid().ToString(); // uniq random string context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z"; // get current time in UTC ProcessPostDataByRazor(currentTask); // the call to process the Post Data content with the Razor engine
The result HTTP request will look similar to this:
03:15:23 POST https://www.dotcom-monitor.com/CheckIn { "CheckInTime": "2021-03-30T08:15:22.0Z", "GenGuid": "5c5e3d23-66fd-49d0-bd57-62c516aea7e7" }In the next step, we need to configure the HTTP request to submit an order. In order to do this, we will pass the order current time and session ID, along with the item’s model identification number, in the JSON body to the target endpoint. See the JSON body for this request below:
{ "OrderTime": "@Model["OrderTime"]", "VIEWSTATE": "@Model["Session"]", "ModelID": "2128506" }To pass a value of the current session ID variable, we need to retrieve it from the login page, called at the first login step, using the View State method. It can be coded in the prepare script. Additionally, to simulate a real user’s think time, we will set the order time variable with a three minute offset. Therefore, the Prepare Script field will contain the following strings:
context.OrderTime = DateTime.Now.AddMinutes(3).ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z"; // order time + 3 min context.Session = (Tasks["Login"] as Http).body["//INPUT[@ID='__VIEWSTATE']", "VALUE"]; // track state value from Login page ProcessPostDataByRazor(currentTask);
The resulting HTTP request will look similar to this:
03:15:45 POST https://www.dotcom-monitor.com/Order { "OrderTime": "2021-03-30T08:18:45.0Z", "VIEWSTATE": "<Server Generated ViewState>", "ModelID": "2128506" }
To learn how to configure an HTTP request with a dynamically changing payload, see How to Dynamically Change Payload in HTTP Request.
DNS オプション
DNS オプション機能を使用すると、監視タスク中にドメイン ネーム サーバー (DNS) 要求を実行する方法をユーザーが選択できます。
ホスト名の解決モードを指定するには 、[DNS 解決モード] セクションで、使用可能なモードのいずれかを選択します。 機能の構成の詳細については 、「DNS モード オプション」を参照してください。
[Custom DNS Hosts] セクションでは、IP アドレスとホスト名のマッピングを設定できます。 IPv6 および IPv4 DNS 解決がサポートされています。
マッピングを指定するには、対応するフィールドに IP アドレスとホスト名を入力します。
例：
192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com
参照 : DNS モード オプション
スクリプトとポスト スクリプトの準備
The fields can contain C# code, which can be used for specific POST, GET, URL data or for validating or publishing custom headers. Please see the Using Prepare Script and Post Script article or contact technical support for more details on usage.