You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a question about a potential change I'd like to make than an issue. While using Http.fs to connect to Amazon's new product advertising API, I ran into a road-block around setting one of the request headers. Their API requires a Content-Encoding header to be set on the request (who does this?). Anyway, since this is technically a "content header", it's not possible to set it this way:
The underlying .net HttpRequestHeaders just isn't having any of these shenanigans, and will refuse to add the header.
I tried working around the issue by adding it as a default header on the HttpClient instance, but since it's content header, it needs to be set on the content of an actual request.
It applies to all Custom headers that start with the string "Content-". I feel like this could be a potentially breaking API change or at least cause some unintended problems for people.
Perhaps I could add a new RequestHeader.ContentEncoding value to the DU that functions similarly to the ContentType header? It's not technically a request header, but it's consistent with the way the API handles the other content headers.
This is more of a question about a potential change I'd like to make than an issue. While using Http.fs to connect to Amazon's new product advertising API, I ran into a road-block around setting one of the request headers. Their API requires a
Content-Encoding
header to be set on the request (who does this?). Anyway, since this is technically a "content header", it's not possible to set it this way:The underlying .net HttpRequestHeaders just isn't having any of these shenanigans, and will refuse to add the header.
I tried working around the issue by adding it as a default header on the
HttpClient
instance, but since it's content header, it needs to be set on the content of an actual request.I attempted a temporary work-around in my own fork of Http.fs that I'm not particularly satisfied with: HoraceGonzalez@b2ea9d8#diff-f07862fe9695509b6f1d49af7970ec28R695
It applies to all
Custom
headers that start with the string"Content-"
. I feel like this could be a potentially breaking API change or at least cause some unintended problems for people.Perhaps I could add a new
RequestHeader.ContentEncoding
value to the DU that functions similarly to theContentType
header? It's not technically a request header, but it's consistent with the way the API handles the other content headers.Any thoughts, @haf?
The text was updated successfully, but these errors were encountered: