7 Response (Réponse)
7 Response (Réponse)
[H6] s'applique, sauf que HTTP-Version est remplacé par RTSP-Version. De plus, RTSP définit des codes de statut supplémentaires et ne définit pas certains codes HTTP. Les codes de réponse valides et les méthodes avec lesquelles ils peuvent être utilisés sont définis dans le tableau 1.
Après réception et interprétation d'un message de requête, le destinataire répond par un message de réponse RTSP.
Response = Status-Line ; Section 7.1
*( general-header ; Section 5
| response-header ; Section 7.1.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
7.1 Status-Line (Ligne de statut)
La première ligne d'un message Response est la Status-Line, composée de la version du protocole suivie d'un code de statut numérique et de la phrase textuelle associée au code de statut, chaque élément étant séparé par des caractères SP. Aucun CR ni LF n'est autorisé sauf dans la séquence CRLF finale.
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
7.1.1 Status Code and Reason Phrase (Code de statut et phrase de raison)
L'élément Status-Code est un code résultat entier à 3 chiffres de la tentative de comprendre et satisfaire la requête. Ces codes sont entièrement définis à la section 11. La Reason-Phrase vise à donner une brève description textuelle du Status-Code. Le Status-Code est destiné aux automates et la Reason-Phrase à l'utilisateur humain. Le client n'est pas tenu d'examiner ou d'afficher la Reason-Phrase.
Le premier chiffre du Status-Code définit la classe de réponse. Les deux derniers chiffres n'ont pas de rôle de catégorisation. Il y a 5 valeurs pour le premier chiffre :
-
1xx : Informatif - Requête reçue, processus en cours
-
2xx : Succès - L'action a été reçue, comprise et acceptée avec succès
-
3xx : Redirection - Une action supplémentaire doit être entreprise pour achever la requête
-
4xx : Erreur client - La requête contient une syntaxe incorrecte ou ne peut être satisfaite
-
5xx : Erreur serveur - Le serveur n'a pas pu satisfaire une requête apparemment valide
Les valeurs individuelles des codes de statut numériques définis pour RTSP/1.0, et un ensemble d'exemples de Reason-Phrase correspondantes, sont présentées ci-dessous. Les phrases de raison listées ici ne sont que recommandées - elles peuvent être remplacées par des équivalents locaux sans affecter le protocole. Notez que RTSP adopte la plupart des codes de statut HTTP/1.1 [2] et ajoute des codes spécifiques RTSP à partir de x50 pour éviter les conflits avec de nouveaux codes HTTP.
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "250" ; Low on Storage Space
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood
| "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth
| "454" ; Session Not Found
| "455" ; Method Not Valid in This State
| "456" ; Header Field Not Valid for Resource
| "457" ; Invalid Range
| "458" ; Parameter Is Read-Only
| "459" ; Aggregate operation not allowed
| "460" ; Only aggregate operation allowed
| "461" ; Unsupported transport
| "462" ; Destination unreachable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; RTSP Version not supported
| "551" ; Option not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
Les codes de statut RTSP sont extensibles. Les applications RTSP ne sont pas tenues de comprendre la signification de tous les codes enregistrés, bien qu'une telle compréhension soit souhaitable. Cependant, les applications MUST comprendre la classe de tout code de statut, indiquée par le premier chiffre, et traiter toute réponse non reconnue comme équivalente au code x00 de cette classe, à l'exception qu'une réponse non reconnue MUST NOT être mise en cache. Par exemple, si le client reçoit un code 431 non reconnu, il peut supposer en toute sécurité qu'il y avait un problème avec sa requête et traiter la réponse comme s'il avait reçu un code 400. Dans de tels cas, les agents utilisateurs SHOULD présenter à l'utilisateur l'entité renvoyée avec la réponse, car cette entité inclura probablement des informations lisibles expliquant le statut inhabituel.
Tableau 1 : Codes de statut et utilisation avec les méthodes RTSP
| Code | Phrase de raison | Méthode |
|---|---|---|
| 100 | Continue (poursuite) | all |
| 200 | OK | all |
| 201 | Created (créé) | RECORD |
| 250 | Low on Storage Space (peu d'espace de stockage) | RECORD |
| 300 | Multiple Choices (choix multiples) | all |
| 301 | Moved Permanently (déplacé définitivement) | all |
| 302 | Moved Temporarily (déplacé temporairement) | all |
| 303 | See Other (voir ailleurs) | all |
| 305 | Use Proxy (utiliser un mandataire) | all |
| 400 | Bad Request (requête incorrecte) | all |
| 401 | Unauthorized (non autorisé) | all |
| 402 | Payment Required (paiement requis) | all |
| 403 | Forbidden (interdit) | all |
| 404 | Not Found (introuvable) | all |
| 405 | Method Not Allowed (méthode non autorisée) | all |
| 406 | Not Acceptable (inacceptable) | all |
| 407 | Proxy Authentication Required (authentification mandataire requise) | all |
| 408 | Request Timeout (délai de requête dépassé) | all |
| 410 | Gone (disparu) | all |
| 411 | Length Required (longueur requise) | all |
| 412 | Precondition Failed (précondition échouée) | DESCRIBE, SETUP |
| 413 | Request Entity Too Large (entité de requête trop grande) | all |
| 414 | Request-URI Too Long (Request-URI trop long) | all |
| 415 | Unsupported Media Type (type de média non pris en charge) | all |
| 451 | Invalid parameter (paramètre invalide) | SETUP |
| 452 | Illegal Conference Identifier (identifiant de conférence illégal) | SETUP |
| 453 | Not Enough Bandwidth (bande passante insuffisante) | SETUP |
| 454 | Session Not Found (session introuvable) | all |
| 455 | Method Not Valid In This State (méthode invalide dans cet état) | all |
| 456 | Header Field Not Valid (champ d'en-tête invalide) | all |
| 457 | Invalid Range (plage invalide) | PLAY |
| 458 | Parameter Is Read-Only (paramètre en lecture seule) | SET_PARAMETER |
| 459 | Aggregate Operation Not Allowed (opération d'agrégation non autorisée) | all |
| 460 | Only Aggregate Operation Allowed (seule opération d'agrégation autorisée) | all |
| 461 | Unsupported Transport (transport non pris en charge) | all |
| 462 | Destination Unreachable (destination inaccessible) | all |
| 500 | Internal Server Error (erreur interne du serveur) | all |
| 501 | Not Implemented (non implémenté) | all |
| 502 | Bad Gateway (mauvaise passerelle) | all |
| 503 | Service Unavailable (service indisponible) | all |
| 504 | Gateway Timeout (délai de passerelle dépassé) | all |
| 505 | RTSP Version Not Supported (version RTSP non prise en charge) | all |
| 551 | Option not support (option non prise en charge) | all |
7.1.2 Response Header Fields (Champs d'en-tête de réponse)
Les champs response-header permettent au destinataire de la requête de transmettre des informations supplémentaires sur la réponse qui ne peuvent figurer dans la Status-Line. Ces champs donnent des informations sur le serveur et sur un accès ultérieur à la ressource identifiée par le Request-URI.
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
Les noms de champs response-header ne peuvent être étendus de manière fiable qu'en combinaison avec un changement de version du protocole. Toutefois, de nouveaux champs d'en-tête expérimentaux MAY recevoir la sémantique de champs response-header si toutes les parties de la communication les reconnaissent comme tels. Les champs d'en-tête non reconnus sont traités comme des champs entity-header.