ERROR: Could not save '/..../ .json' : Expecting value: line 1 column 1 (char 0) about redfish-mockup-creator HOT 17 CLOSED

Can you post the contents of the /redfish/v1/SchemaStore/en/Certificate.json resource returned by the service?

from redfish-mockup-creator.

The times I've seen that error are when the payload is not valid JSON. The contents of the resource will help show that.

from redfish-mockup-creator.

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

@jautor @malhotrs

from redfish-mockup-creator.

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.

from redfish-mockup-creator.

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

from redfish-mockup-creator.

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 ?

from redfish-mockup-creator.

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).

from redfish-mockup-creator.

Here it is.

CurlUnCompressed.txt

from redfish-mockup-creator.

Here it is.

CurlUnCompressed.txt

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.

from redfish-mockup-creator.

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

from redfish-mockup-creator.

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.

from redfish-mockup-creator.

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.

from redfish-mockup-creator.

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.

from redfish-mockup-creator.

Thanks for confirming that.

from redfish-mockup-creator.

@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

from redfish-mockup-creator.

Tested successfully against iLO 5 versions: 2.30, 2.33 and 2.18 (for backward compatibility).

Waiting for final release before closing issue.

Thanks.

from redfish-mockup-creator.

Thanks for confirming!

from redfish-mockup-creator.