POST – Mise à jour HTTP Push pour le microprogramme
Cette opération permet d’effectuer une mise à jour des composants logiciels installés en envoyant un fichier image de logiciel vers l’URI référencé par la propriété UpdateService.HttpPushUri.
URL de demande
https://<SMM_IPADDR>/redfish/v1/UpdateService/update
Corps de la demande
Le POST de cet URI doit fournir une authentification avec le même privilège que celui utilisé pour accéder à UpdateService.
- « X-Auth-Token » à l’aide d’un jeton existant ou d’un nouveau jeton
- En-tête « Authorization » DE BASE afin de préciser les identifiants de l’utilisateur.
Corps de la réponse
La mise à jour Http Push prend en charge le téléchargement des fichiers qui utilisent la publication de données binaires (par exemple, l’option curl –data-binary, en supposant que l’encodage du contenu du corps est application/octet-stream). Elle prend également en charge le téléchargement de fichiers par le biais de la méthode form POST qui équivaut à effectuer l’opération « curl -F » qui indique l’en-tête « Content-Type: mulitpart/form-data ».
Si le client télécharge plusieurs fichiers dans la même requête POST, seul le premier sera accepté et les autres seront ignorés.
Le client peut éventuellement inclure l’en-tête « Content-Length » sur le POST pour indiquer la taille du corps du POST. SMM vérifie cet en-tête et s’assure que la taille se situe dans la plage des tailles maximale prise en charge du fichier pour les mises à jour du microprogramme. Si le fichier est plus volumineux que ce que le service prend en charge, le service renvoie le code 413 (entité de demande trop volumineuse) avec un message d’erreur indiquant que la taille du fichier est trop grande.
Le « Content-Length » indiqué doit être compris entre 0 et 2147483647 (0 et 0x7FFFFFFF). Sinon, HTTP 400 sera renvoyé.
Le client peut éventuellement inclure des données de formulaire HTTP à plusieurs parties dans les données du corps POST afin de préciser le nom du fichier image, tel que défini dans RFC2388. C’est l’équivalent d’une opération « curl -F ». Ceci est facultatif et le service ne doit pas l’exiger. Si le client télécharge plusieurs fichiers dans la même requête POST, le service renvoie un HTTP 400 (demande incorrecte) avec un message d’erreur indiquant que le format n’est pas pris en charge.
Si une autre mise à jour du microprogramme POST vers HttpPushUri est effectuée alors que le service est en train de flasher la mise à jour précédente, le service accepte la demande et télécharge le fichier. Si la mise à jour est toujours en cours lorsque le téléchargement du fichier est terminé, le service renvoie une erreur ResourceInUse dans la ressource de la tâche indiquant que le service de mise à jour est occupé et rejette la mise à jour Push.
Même s’il s’agit d’URI individuels, le téléchargement d’un fichier via HttpPushUri peut être rejeté avec 409 Conflict si un téléchargement de fichier via MultipartHttpPushUri est en cours, et vice versa.
Code d’état
| Code d’état HTTP | ID de message d’erreur |
|---|---|
| 401 | Absence d’autorisation |
| 403 | Interdit |
| 503 | Service temporairement indisponible |
| 500 | Erreur interne |
| 202 | Acceptation |
Exemple
L’exemple du téléchargement push :
Envoyez l’image du microprogramme à l’URL de la propriété HttpPushUri.
Vous trouverez ci-dessous un exemple de commande curl pour la requête de mise à jour push HTTP pour UEFI.
curl -k -H <Authentication> -H "Content-Type: application/octet-stream" -T <firmware image>https://{SMM3 IP}:{SMM3 port}/redfish/v1/UpdateService/updateRemarque- <Authentication>
- BasicAuth (exemple : -u user:password, ou -H “X-Auth-Token : Basic <encoding string>")
- X-Auth-Token (exemple : -H “X-Auth-Token: <token string>”)
- <firmware image>
- exemple : « lnvgy_fw_smm3_q4sm01a-1.0.00_anyos_comp.uxz »