Replies: 1 comment 3 replies
-
Nah we don't add any automatic stuff to the request, so you should be fine. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello.
I am currently looking into writing a set of components to allow forwarding logs written to frameworks such as Logback, JUL, Log4J2, etc to Cloud log providers such as AWS CloudWatch, Kinesis Firehose, Kafka, etc.
One of my requirements is to remain as lightweight as possible. To do this, I have opted to not use the existing AWS SDKs (since I would end up pulling in something like 16 JARs, including Netty, just to perform HTTP requests to two endpoints). This means I need to implement AWS4 HMAC-SHA256 request signing.
The flow for doing this is a bit complex, and requires that I have full control over the HTTP headers being sent in the request. I've attached a diagram below that demonstrates this process. It is fairly complex internally and has a number of additional constraints on what constitutes a canonical and a signed header which I have also linked below.
https://docs.aws.amazon.com/IAM/latest/UserGuide/create-signed-request.html
Avaje-HTTP looks like it will be a good fit to abstract away integrating with HTTP clients directly without adding too much additional overhead (along with Avaje-JSON). I wanted to make sure that there is no caveats with using this tool for what I am trying to achieve though (e.g. no additional headers being silently injected, being able to directly enforce using HTTP/1.1 where possible, etc).
Is there any immediate things that come to mind that wouldn't work with this? I can see the
RequestIntercept
interface is probably going to be ideal for injecting in this signing process.Thanks!
Beta Was this translation helpful? Give feedback.
All reactions