XDebug プラグイン¶
The XDebug plugin allows HTTP clients to debug the operation of
the Traffic Server cache using the default X-Debug
header. The plugin
is triggered by the presence of the X-Debug
or the configured header in
the client request. The contents of this header should be the names of the
debug headers that are desired in the response. The XDebug plugin
will inject the desired headers into the client response. In addition, a value of the
form fwd=n
may appear in the X-Debug
header, where n
is a nonnegative
number. If n
is zero, the X-Debug
header will be deleted. Otherwise, n
is
decremented by 1. =n
may be omitted, in which case the X-Debug
header will
not be modified or deleted.
XDebug はグローバルなプラグインです。plugin.config
ファイルに追加することでインストールされます。現時点では単一の省略可能な設定オプション --header
を受け取ります。例えば
--header=ATS-My-Debug
This overrides the default X-Debug
header name.
All the debug headers are disabled by default, and you need to enable them
selectively by passing header names to --enable
option.
--enable=x-remap,x-cache
This enables X-Remap
and X-Cache
. If a client's request has
X-Debug: x-remap, x-cache, probe
, XDebug will only injects X-Reamp
and
X-Cache
.
ヘッダーのデバッグ¶
XDebug プラグインは次のデバッグヘッダーを生成することができます。
- Via
Via
ヘッダーがリクエストされた場合、XDebug プラグインはそのリクエストのproxy.config.http.insert_response_via_str
設定変数に3
を設定します。- Diags
If the
Diags
header is requested, the XDebug plugin enables the transaction specific diagnostics for the transaction. This also requires thatproxy.config.diags.debug.enabled
is set to1
.- Probe
All request and response headers are written to the response body. Because the body is altered, it disables writing to cache. In conjunction with the fwd tag, the response body will contain a chronological log of all headers for all transactions used for this response.
Layout:
Request Headers from Client -> Proxy A
Request Headers from Proxy A -> Proxy B
Original content body
Response Headers from Proxy B -> Proxy A
Response Headers from Proxy A -> Client
- X-Cache-Key
The
X-Cache-Key
header contains the URL that identifies the HTTP object in the Traffic Server cache. This header is particularly useful if a custom cache key is being used.- X-Cache
The
X-Cache
header contains the results of any cache lookups.値
解説
none
No cache lookup was attempted.
miss
The object was not found in the cache.
hit-stale
The object was found in the cache, but it was stale.
hit-fresh
The object was fresh in the cache.
skipped
The cache lookup was skipped.
If a request goes through multiple proxies, each one appends its X-Cache header content the end of the existing X-Cache header. This is the same order as for the
Via
header.- X-Cache-Generation
The cache generation ID for this transaction, as specified by the
proxy.config.http.cache.generation
configuration variable.- X-Milestones
The
X-Milestones
header contains detailed information about how long the transaction took to traverse portions of the HTTP state machine. The timing information is obtained from theTSHttpTxnMilestoneGet()
API. Each milestone value is a fractional number of seconds since the beginning of the transaction.- X-Transaction-ID
A unique transaction ID, which identifies this request / transaction. This matches the log field format that is also available, %<cruuid>.
- X-Remap
If the URL was remapped for a request, this header gives the to and from field from the line in remap.config that caused the URL to be remapped.
- X-Effective-URL
If the URL was remapped for a request, this header gives the URL resulting from the remapping. Note that if there are multiple remaps, this header aggregates the URLs, space-comma-separated. The URLs are inside doublequotes.
- X-ParentSelection-Key
The
X-ParentSelection-Key
header contains the URL that is used to determine parent selection for an object in the Traffic Server. This header is particularly useful if a custom parent selection key is being used.