4. Messages de requête et de réponse Heartbeat

Les messages du protocole Heartbeat se composent de leur type, d'une charge utile (payload) arbitraire et d'un remplissage (padding).

struct {
   HeartbeatMessageType type;
   uint16 payload_length;
   opaque payload[HeartbeatMessage.payload_length];
   opaque padding[padding_length];
} HeartbeatMessage;

La longueur totale d'un HeartbeatMessage NE DOIT PAS (MUST NOT) dépasser 2^14 ou max_fragment_length lors de la négociation, comme défini dans [RFC6066].

type: Le type de message, soit heartbeat_request soit heartbeat_response.

payload_length: La longueur de la charge utile.

payload: La charge utile consiste en un contenu arbitraire.

padding: Le remplissage est un contenu aléatoire qui DOIT (MUST) être ignoré par le récepteur. La longueur d'un HeartbeatMessage est TLSPlaintext.length pour TLS et DTLSPlaintext.length pour DTLS. De plus, la longueur du champ type est de 1 octet et la longueur de payload_length est de 2. Par conséquent, la padding_length est TLSPlaintext.length - payload_length - 3 pour TLS et DTLSPlaintext.length - payload_length - 3 pour DTLS. La padding_length DOIT (MUST) être d'au moins 16.

L'expéditeur d'un HeartbeatMessage DOIT (MUST) utiliser un remplissage aléatoire d'au moins 16 octets. Le remplissage d'un message HeartbeatMessage reçu DOIT (MUST) être ignoré.

Si la payload_length d'un HeartbeatMessage reçu est trop grande, le HeartbeatMessage reçu DOIT (MUST) être abandonné silencieusement.

Lorsqu'un message HeartbeatRequest est reçu et que l'envoi d'un HeartbeatResponse n'est pas interdit comme décrit ailleurs dans ce document, le récepteur DOIT (MUST) envoyer un message HeartbeatResponse correspondant portant une copie exacte de la charge utile du HeartbeatRequest reçu.

Si un message HeartbeatResponse reçu ne contient pas la charge utile attendue, le message DOIT (MUST) être abandonné silencieusement. S'il contient bien la charge utile attendue, le temporisateur de retransmission DOIT (MUST) être arrêté.