ERROR: Could not save '/..../ .json' : Expecting value: line 1 column 1 (char 0)
donzef opened this issue · 17 comments
With version 1.0.8, against HPE iLO 5 version 2.30 I am getting numerous errors like the following:
Getting /redfish/v1/JsonSchemas/Certificate...
Getting /redfish/v1/SchemaStore/en/Certificate.json...
ERROR: Could not save '/redfish/v1/SchemaStore/en/Certificate.json': Expecting value: line 1 column 1 (char 0)
Everything working fine with iLO 5 version 2.18.
@jautor @malhotrs
Let me know what I can do to provide more debug info to isolate the problem in iLO 5 or in Mockup Creator.
Can you post the contents of the /redfish/v1/SchemaStore/en/Certificate.json resource returned by the service?
The times I've seen that error are when the payload is not valid JSON. The contents of the resource will help show that.
The attached screenshot shows a curl GET request against an iLO 5 version 2.30 of a Schemastore path with NO headers. Curl detects that the response is a binary file and refuses to display it on stdout.
The second request provides an output file to cURL. This file appears to be a gzip file after the GET request is sent, while the request does not specify any Accept-Encoding header.
While in touch with iLO developers, I received the following:
"In 2.30 iLO added a check. If the client sends the "Accept-Encoding" header and the value of the header is neither “gzip” nor “*” , then iLO responds with error 406 (Not Acceptable). If the client does not send the "Accept-Encoding" header, iLO sends the schema/registries in gzip format."
Use cut/past to reproduce at your place on a Linux system:
ilo5URI=https://
User=UserName
Password=MyPassword
curl --insecure --basic --user ${User}:${Password} --request GET ${ilo5URI}/redfish/v1/SchemaStore/en/Certificate.json
curl --insecure --basic --user ${User}:${Password} --request GET ${ilo5URI}/redfish/v1/SchemaStore/en/Certificate.json --output OutputFile
file OutputFile
Since we replaced the lower request handler with the Python library, were not sending the Accept-Encoding header in this request. Since we're not explicitly requesting any encoding, I'd expect the response to come back as JSON.
The python-redfish-library should be taking care of uncompressing. Can you run the command like this and show the output? (I added --include and --compress to include the response headers and do the decompressing)
curl --insecure --include --compressed --basic --user ${User}:${Password} --request GET ${ilo5URI}/redfish/v1/SchemaStore/en/Certificate.json
Asking cURL to accept gzip encoding does returns valid response. However, not sure how to ask the Mockup Creator to accept gzip compression.
@jautor @malhotrs , would you be kind to comment the bullet in the Media Types paragraph from DSP0266_1.6.0 specifying All resources shall be made available using the JSON media type ?
As I mentioned above, the python-redfish-library should be taking care of uncompressing, so there should be no need for the Mockup Creator to do anything special to handle the gzip encoding. See https://github.com/DMTF/python-redfish-library/blob/f79d28b44ae78ca5b785d43c04bb3b07b7e9b2f5/src/redfish/rest/v1.py#L886-L889
I asked for the output of the above command because I would like to take a close look at the full JSON payload. Please rerun the command and capture the full output and paste or attach it here (as text, not as a screenshot).
Here it is.
Here it is.
Thanks. That JSON looks to be valid. So I'm not sure exactly what is happening. I'll try and reproduce this on one of the iLOs I have access to.
I reproduced the problem.
The Redfish-Mockup-Creator uses python-redfish-library. And python-redfish-library uses the Python http.client. And http.client adds an Accept-Encoding: identity header to outgoing requests (if there is not already an Accept-Encoding header supplied by the caller). The iLO is returning a 406 Not Acceptable for those JSON schema resources. You can reproduce this in curl by adding that header:
curl --insecure --include --compressed -H "Accept-Encoding: identity" --basic --user ${User}:${Password} --request GET ${ilo5URI}/redfish/v1/SchemaStore/en/Certificate.json
On the iLO service I have access to with the 2.30 firmware, the response looks like this:
HTTP/1.1 200 Connection established
HTTP/1.1 406 Not Acceptable
Allow: GET, HEAD
Content-Length: 0
Date: Sun, 13 Dec 2020 21:52:06 GMT
OData-Version: 4.0
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Connection: keep-alive
I think we might need to discuss this in the forum a bit. I wasn't aware that Accept-Encoding was being added, but since it's passing "identity", I would think that should be considered valid and ensure no compression is performed. But, the Redfish spec today does not call out this case; it only documents when compression is permitted.
Just for clarity with the behavior of the iLO, what happens if Accept-Encoding is not in the request? Does the response come back compressed? From earlier comments, that seems to be the case, which would need to be addressed by the service I believe.
Just for clarity with the behavior of the iLO, what happens if Accept-Encoding is not in the request? Does the response come back compressed? From earlier comments, that seems to be the case, which would need to be addressed by the service I believe.
Yes, I just tested and confirmed that when no Accept-Encoding header is sent in the request, the response comes back gzip-compressed.
Thanks for confirming that.
@donzef can you try again with a branch I just pushed (the branch is named Accept-Encoding)?
https://github.com/DMTF/Redfish-Mockup-Creator/tree/Accept-Encoding
Tested successfully against iLO 5 versions: 2.30, 2.33 and 2.18 (for backward compatibility).
Waiting for final release before closing issue.
Thanks.
Thanks for confirming!