Acccept gzip encoded return files

[donzef]

As a python new bee, the only way I found to create a valid Mockup from a Redfish server gzip encoding in its responses is to modify two lines in redfishtoolTransport.py:

Replace line 443 with:
hdrs['Accept-Encoding']="gzip"

Replace line 74 with:
self.dfltGetDeleteHeadHdrs = {'Accept': 'application/json', 'OData-Version': '4.0', 'Accept-Encoding': 'gzip'}

Is there a better way to achieve this ?

[mraineri]

At least with the way the tool works today, you seem to be doing the right thing. Redfish services are only supposed to send gzip encoded responses when a client advertises it supports it too, and the tool doesn't allow a client to specify this on the command line.

However, what's the need to accept gzip encoded responses? Do you have a large service and want to cut down on possible transmission time?

[donzef]

In an attempt to promote Redfish on HPE iLO 5, I am building an infra pulling off an entire iLO 5 Redfish tree using the Mockup Creator and redistribute the content via Mockup Server to students.

The default Mockup Creator works fine up to iLO 5 Firmware 2.18. However, starting at 2.30 (very recently), iLO compresses part of its resource trees. I am getting 406 HTTP status codes on all of the compressed sub-trees.

Allowing the Mockup Creator to accept gzip encoding solves all my problems.

Should it be cleaner to ask the iLO Redfish server to behave differently ?

Thanks,
François Donzé

[mraineri]

@jautor you may want to take a look at this on your end.

It sounds like iLO 2.30 has a bug; services are not supposed to gzip encode responses unless the client requests for it. The only time I'd expect 406 to be returned from a service is when a client requests for gzip encoding, but the service is not able to send a gzip response.

[donzef]

Closing.

Sorry for the interruption, I should have read paragraph 6.14 of the specs before shouting.

@jautor, I'll do the follow-up internally.

Thanks,