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
1.4 breaks custom headers on PUT HTTP requests #834
Comments
Seems like fa8b121#diff-943160e99ba2b155e41572bfd0414d10 changed the way The only occurence of
Headers is not passed into BulkDownloaderOptions which might explain the fact that the missing headers only occur when downloading attachments.
|
The custom headers are part of the overall remote session object now, so they should persist throughout all parts of the replicator's lifetime. The reason they are not passed in anymore is because instead of creating a new http client for itself, it reuses the existing one. That being said, the complexity of the replicator has probably led to another error on my part (this is one of the big overhauls being done for 2.0, to prevent these kinds of things from popping up again and again) so can you let me know how you are setting these headers? |
Here's the snippet right from our code which sets the header, where if (replication.Headers != null)
{
replication.Headers = new Dictionary<string, string>();
}
replication.Headers.Add("Authorization", $"Bearer {bearerToken}"); |
Having a closer (and especially fresh look after the week-end) on the logs it's actually the uploading of attachments which fails. A small peek into the code might suggest that i.e. a comparison of and might suggest that there's a |
That does seem quite likely. I'll put in that change and it will be in the next CI build soon (1.4.1-65 or higher) |
Perfect, 1.4.1-b0065 solves the issue. Thanks a lot for the quick reaction! |
Hi,
we are just about to upgrade to the latest 1.4 release and we're hitting a new issue concerning custom headers. We're in the same scenario as described in #687, however we now see request being send without the custom headers being set. We're still investigating for further details, but it seems like only requests for attachments are affected.
Best,
Daniel
The text was updated successfully, but these errors were encountered: