COMMON
Common specs to all task protocol specs with some specific explanations on some goal.
Hint
Supported since GLPI 10.0.0
Transport protocol
Messages are passed between client and server via HTTP or HTTPS protocol.
HTTP headers
GLPI-Agent-ID
- An agent identity MUST be set in HTTP headers:
This is the agentid
agentid HTTP header:
GLPI-Agent-ID
agentid format: plain text UUID which can be reduced in a 128 bits raw id by code
example:
3a609a2e-947f-4e6a-9af9-32c024ac3944
it is generated by the agent the first time it starts
server must also set it in answer to specify agent destination, this can be used by a proxy agent to route server answer
GLPI-Request-ID
- A request id CAN be set in HTTP headers:
HTTP header:
GLPI-Request-ID
format: a 8 digit hexadecimal string in higher case like
42E6A9AF1
When present, it MUST be set back in answer
When present, it SHOULD be logged
It MUST be set by a proxy in an answer when the answer is still not definitively known
It MUST be set when using a GET request to query the final request status from a proxy. It MUST then be identical the the one provided by the previous proxy answer.
Content-Type
- The content type MUST be set in HTTP headers and follow the official public specs:
HTTP header:
Content-Type
The following content type are to be supported:
application/json
: MANDATORY SUPPORT This format must be supported as this will be the default formatapplication/x-compress-zlib
: Compressed JSON with zlib compressionapplication/x-compress-gzip
: Compressed JSON with gzip compressionapplication/x-compress-br
: Compressed JSON with brotli compressionapplication/xml
: Only for [CONTACT](specs/CONTACT) protocol
Accept
- A party CAN announce which content types it supports setting
Accept
HTTP header HTTP header:
Accept
format: must follow RFC7231
can be used to try another content type on "unsupported content-type" error
Example:
Accept: application/json
Accept: application/xml; q=0.1, application/json; q=0.5, application/x-compress-zlib; q=0.7, application/x-compress-gzip; q=0.8, application/x-compress-br
Pragma
- The agent requests MUST includes the pragma header to avoid any caching done by the server:
HTTP header and value:
Pragma: no-cache
GLPI-CryptoKey-ID
- If an encryption key has been shared and encryption is enabled, a side party must announce the key owner used to encrypt data: this is generally agentid
HTTP header:
GLPI-CryptoKey-ID
format: same as agentid
the same encryption should be used when answering unless encryption is disabled on a side
in a proxy context, this id can be different than
GLPI-Agent-ID
when this header is missing, data are not expected to be encrypted
GLPI-Proxy-ID
- When a GLPI-Agent is used as a proxy, it MUST set/update this HTTP header with its own agentid.
HTTP header:
GLPI-Proxy-ID
format: list of agentid separated by commas
a proxy agent must check its agentid is still not in the list, otherwise it MUST answer a HTTP 404 error with a JSON error message (see below): "proxy-loop-detected"
a proxy agent parameter should define the maximum number of proxy to be set in the list. In the case, the header reaches the maximum on a proxy, it MUST answer a HTTP 404 error with a JSON error message (see below): "too-many-proxy". By default, the maximum number of proxy should be set to 5 as that's still large and most usercase will only use 1 proxy.
GLPI server should show the proxy list in the agent management panel.
JSON template messages
Requests
{
"action": "<token>"
}
- Description:
"action": [optional] but should be set to a supported token otherwise action defaults to inventory and then MUST respect the INVENTORY protocol specs.
Answers
{
"status": "<token>",
"message": "<string>",
"expiration": "<delay definition>"
}
- Description:
"status": [mandatory] the resulting status of the request related to the action. Must be a supported token, see related protocol.
Common tokens: "pending", "error", "ok"
The "pending" token with a short "expiration" delay could be used by proxy agents to tell agents to retry the same request soon as the proxy has the time to obtain the server expected answer.
"message": [optional] a message to keep in log as an error reason or for debugging purpose
"expiration": [optional] the delay before the agent can send another message for the current action. The delay may have different meanings regarding the related action. The delay definition must be a positive integer number immediately followed by an optional letter defining the number unit. The letter should be one of "s", "m", "h", "d" which are respectively representing seconds, minutes, hours and days. The default is "h" when no unit follows the number.
if not set, no delay is required and next request can be handled immediately
in case of error or no answer, the latest delay or configured one should be used by the client
example: "1d", "24", "1m", "30s", "6h"
Error answers
{
"status": "error",
"message": "unsupported content-type"
}
- Description:
On error, the HTTP answer error code MUST be set with the 4XX or 5XX HTTP related error
For 4XX errors, status code in free, but the answer SHOULD be a short JSON message with the "error" value set as "status" property and eventually a "message" property to help the other party to analyze the error