I am using github.com/DMTF/Redfish-Service-Validator to validate redfish service if it is in adherence with the schema.
But I am facing an error as mentioned below:
For the Task Collection URI /redfish/v1/TaskService/Tasks , there are four instances or members under it and for one particular instance, when a GET request is issued by the validator, the validator throws the below error -
ERROR - Members: GET of resource at URI /redfish/v1/TaskService/Tasks/2 returned HTTP 202. Check URI.
But as per the DMTF Specification in the link below :
• The Task Monitor is used by the Client to get the Response Body of the actual operation.
• If the operation has been accepted for processing, a 202 can be returned. This mean a Task has been started to complete the request. • The “Location” header is set to the URI of a Task Monitor. • There may also be a “Retry-After” header to specify the amount of time the client should wait before querying the Task Monitor
• When the operation is finished, the Response Body will be returned with the content the same as if the Request had been synchronous.
So , is this a Redfish Service Validator issue ? Please clarify.
Last Edit: Jun 22, 2020 13:02:25 GMT by ginugeorge
There is a distinction to be made between the "Task resource" and the "Task Monitor".
The members of the TaskCollection found in the TaskService will all reference Task resources. In this case, when you perform a GET on the Task resource, you should get back a 200 OK along with the Task representation.
The Task Monitor is a special URI for the requestor of the original operation. You can find the Task Monitor URI within the Task resource itself, but the semantics about responding with a 202 Accepted until the operation is complete is purely unique to the Task Monitor URI.
In addition to the HTTP status differences, there is another key difference in behavior between the Task resource and Task Monitor.
Performing GET operations on a Task resource that represents a completed task will still return the Task resource itself.
Performing GET operations on a Task Monitor for a completed task will return the response for the original operation that generated the task.
It looks like the service validator is correctly identifying an error.