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
{{ message }}
This repository has been archived by the owner on Mar 16, 2021. It is now read-only.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's currently exceedingly difficult for packages to extend HTTP.request by providing a custom layer, which is likely why the logic for an AWS authentication layer is in HTTP rather than AWSCore. I found this out while attempting and failing to write a test that properly exercises the request extension here.
The simplest course of action would be to remove the functionality from this package and instead introduce a dependency on AWSAuth to HTTP, with the request extension using signing defined here.
It's currently exceedingly difficult for packages to extend
`HTTP.request` by providing a custom layer, which is likely why the
logic for an AWS authentication layer is in HTTP rather than AWSCore.
The simplest course of action would be to remove the functionality from
this package and instead introduce a dependency on AWSAuth to HTTP, with
the `request` extension using signing defined here.
Maybe make an issue in HTTP.jl describing why it's difficult to extend HTTP.request with custom layers? This seems like an issue that should be addressed in any further design/refactoring and should be documented.
To be explicit, the hard part is adding the layer to the stack right? The actual creation of the custom layer is easy but getting HTTP to use it is hard?
Yes, what Eric said is exactly right. One can define a Layer subtype with a request method that does what you want, but there are some serious complications. One example is that not every request(::Layer, args...) method takes the same arguments, so to know how to formulate the next call to request in your method, you need to know where in the stack your layer is, so that you know the expected signature for the next call. Internally, HTTP gets around this by having HTTP.stack define the layers in a specific order that works. In that case, the AWS authentication layer is not the outermost layer, and to ensure that this package puts the layer in the same spot, it would need to completely reconstruct the stack by hand, and ensure that any preprocessing that's done in the user-facing request methods that get called before those which take Layers is taken care of. That essentially amounts to a reimplementation of HTTP.request.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It's currently exceedingly difficult for packages to extend
HTTP.request
by providing a custom layer, which is likely why the logic for an AWS authentication layer is in HTTP rather than AWSCore. I found this out while attempting and failing to write a test that properly exercises therequest
extension here.The simplest course of action would be to remove the functionality from this package and instead introduce a dependency on AWSAuth to HTTP, with the
request
extension using signing defined here.