POST – Multipart HTTP Push update for firmware
This operation can perform an update of installed software component(s) by pushing a software image file to the URI referenced by UpdateService.MultipartHttpPushUri property. In XCC3 redfish service, the UpdateService.MultipartHttpPushUri property value is “/redfish/v1/UpdateService/update”.
Request URL
POST https://<BMC_IPADDR>/redfish/v1/UpdateService/update
Request body
The HTTP POST operation shall provide authentication with the sufficient privilege to access the UpdateService resource.
Response
| Field | Type | Description |
|---|---|---|
Id | String | The created task ID. |
Name | String | Task name. |
Description | String | This resource represents a task for a Redfish implementation. |
TaskMonitor | String | The URI of the Task Monitor for this task. |
StartTime | String | The date-time stamp that the task was last started. |
TaskState | String | The state of the task. |
Messages | Array | This is an array of messages associated with the task. |
PercentComplete | Integer | Task completion in percent. |
HidePayload | Boolean | Indicates Payload object is hidden and not returned on GET. |
The client may optionally include HTTP multipart form data in the POST body to specify the image file name as RFC2388 specified.
XCC3 checks this header and verify the size is supported for firmware updates, and returns code 413 when file size is too large.
If the client uploads multiple files in a POST request, it returns code 400 with an error message indicating the format is not supported.
Multipart HTTP push update may be rejected with code 503 when HTTP Push update is in progress, and vice versa.
Status code
| HTTP Status Code | Error Message ID |
|---|---|
| 202 | Accepted |
| 400 | BadRequest, ActionParamMissing, ActionParamTypeError, ActionParamFormatError |
| 401 | AccessDenied |
| 403 | InsufficientPrivilege |
| 413 | RequestEntityTooLarge |
| 500 | InternalError |
| 503 | ServiceUnavailable |
Example
The following example with curl commands is the multipart HTTP push update procedure.
Curl -s -k <Authentication> <Form UpdateParameters> <Form UpdateFile> https://{XCC IP}:{XCC port}/redfish/v1/UpdateService/update
- <Authentication>
Example of basic authentication header to specify the user’s credentials: -u user:password, or -H “X-Auth-Token: Basic <encoding string>”
Example of X-Auth-Token using the existing or new session: -H “X-Auth-Token:<token string>”
- <Form UpdateParameters>
Example: -F ‘UpdateParameters={ “Targets”:[ “/redfish/v1/UpdateService/FirmwareInventory/BMC-Backup” ]};type=application/json’
- Limitations of the JSON body.
The format of the JSON shall follow the definition of the UpdateParameters object in the UpdateService schema.
Any property which is not defined in UpdateParameters object in the UpdateService schema will return “400 Bad Request”.
- For the Targets array.
An empty array or a null item or one URI is allowable.
The URI shall be a resource path to BMC-Backup.
An empty array or a null item means that this POST operation to perform MultipartHttpPushUri firmware update will have the Service apply the firmware image to all applicable targets, except the Backup BMC (BMC-Backup). In this case, only the BMC Primary (BMC-Primary) is updated.
One URI of the BMC-Backup resource in FirmareInventory means that this POST operation to perform MultipartHttpPushUri firmware update will have the Service apply the firmware image only to the Backup BMC (BMC-Backup).
If the image type is Bundle Recipe, the property will be verified as well but the Service will always apply the firmware image to all the applicable targets except BMC-Backup.
For the property @Redfish.OperationApplyTime.
Supported values are “Immediate”, “OnReset”, or “OnStartUpdateRequest”. The Service awaits the condition of “OperationApplyTime” is reached before it starts the firmware update flow.
- <Form UpdateFile>
Example: -F ‘UpdateFile=@xcc-fw.upd;type=application/octet-stream’