-
Notifications
You must be signed in to change notification settings - Fork 177
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
Comments
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. |
The problem is I can`t overwrite these values, so I cannot verify if a service reacts correctly on not expected headers values. |
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. |
Hi, pull request for this topic is created (#94). |
PR merged |
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:
The text was updated successfully, but these errors were encountered: