Closed BlueIce closed 4 weeks ago
Hi @BlueIce , Thank you for the bug report. I created a PR : https://github.com/goharbor/terraform-provider-harbor/pull/472 But I don't have an ALB to test it... So let me know if you can test it before I merge it
I managed to build the provider manually and use it in a local test setup. Using the code from the PR, I was able to successfully run terraform and create some harbor resources (while the loadbalancer was set to strictest
)! :rocket:
And I also cross-checked, that it failed using the code from the main branch (as expected).
hi @BlueIce thanks, I merged it I'll build soon a new release
Describe the bug
When accessing a harbor instance which is behind a AWS Application Load Balancers, GET requests get blocked if "Desync mitigation mode" is set to
strictest
.I think the reason it that for GET (and maybe also HEAD) requests, the
payload
passed to the client isnil
. And when the payload is processed by the json encoder, the byte bufferb
will contain a literalnull
and a newline: https://github.com/goharbor/terraform-provider-harbor/blob/33fc0494c50265a23c15ff91e8b11a1c78b47c5a/client/client.go#L42-L43Which in turn has the effect, that the request will also have a content-length header and a non-empty body. The request gets classified as
Ambiguous
(which means accordings to AWS docs: "Request does not comply with RFC 7230 but poses a risk, as various web servers and proxies could handle it differently."), which is blocked atstrictest
mode. The classification reason isUndefinedContentLengthSemantics
, meaning:To Reproduce
The json encoding part can be reproduced by
This will print:
To reproduce the blocked requests, a AWS Application Load Balancer has to be setup with "Desync mitigation mode" set to strictest.
Expected behavior Request don't get blocked by AWS Application Load Balancer in
strictest
mode.Additional context
Idea to fix the problem: Do not use the json encoder if the
payload
isnil
so that the byte buffer will stay empty.