Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP headers overwritten by library #92

Closed
andrzej-zamojski opened this issue Jul 30, 2020 · 5 comments
Closed

HTTP headers overwritten by library #92

andrzej-zamojski opened this issue Jul 30, 2020 · 5 comments

Comments

@andrzej-zamojski
Copy link

andrzej-zamojski commented Jul 30, 2020

When using the library to verify proper Redfish service implementation behavior I encountered problem with sending a request with headers which value should not be accepted by the service.

It looks like requests with HTTP headers Accept or OData-Version are overwritten by the library, so I could not find a possibility to send for instance 'Accept': 'application/xml' header which should be rejected by the service, because it's overwritten in library with */*. OData-Version 4.0 also cannot be replaced with a value which could be used to verify service implementation.

Is there any explanation for that ?
Is there any chance to change this behavior or make it somehow configurable?
Or maybe I'm doing something wrong ?
Code example below:

import redfish

REDFISH_OBJ = redfish.redfish_client(
        base_url='https://10.172.201.115',
        username='admin', password='admin',
        default_prefix='/redfish/v1')

REDFISH_OBJ.login()
iheaders = {'Accept': 'application/xml'}
response = REDFISH_OBJ.get('/redfish/v1/Managers', headers=iheaders)
print (response)
REDFISH_OBJ.logout()
@mraineri
Copy link
Contributor

I can understand OData-Version being overwritten; anything other than "4.0" is outside scope of the Redfish spec and can result in undefined behavior.

Accept is a bit more problematic though; while the vast majority of Redfish will require "application/json", there are a handful of cases where that won't be the response (primarily $metadata as well as a few URIs that might result in application/octet-stream). I can understand overriding Accept in most cases though.

@andrzej-zamojski
Copy link
Author

The problem is I can`t overwrite these values, so I cannot verify if a service reacts correctly on not expected headers values.
Do you have an idea how to continue?
Propose such change which would not overwrite these headers when are delivered by user?

@mraineri
Copy link
Contributor

I think that sounds reasonable; only add the headers if not already specified by the user. Most users I would expect to never attempt to set these headers.

@andrzej-zamojski
Copy link
Author

Hi, pull request for this topic is created (#94).

@mraineri
Copy link
Contributor

mraineri commented Aug 7, 2020

PR merged

@mraineri mraineri closed this as completed Aug 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants