Status Update
No update yet.
Comments
js...@google.com
Thank you for reporting this issue. Currently the GCP team is aware that the X-Forwarded-For doesn't respect RFC7239, and it's currently being worked on.
Further communications will be made in this thread, however I cannot promise an ETA for the resolution of this issue.
ya...@comuny.de
sa...@gmail.com
ma...@funkemedien.de
la...@google.com
Hello, we have raised the priority of this issue to the highest, since spring-boot is a major web development framework.
The Cloud Run Product Team is currently working on this issue although there is no ETA that I can provide to you. If any other update happens it will be posted here.
wi...@google.com
Assigning to the dev oncall for triage
bk...@google.com
wh...@google.com
mt...@google.com
sr...@google.com
sr...@google.com
va...@gmail.com
co...@onlyonecard.eu
pr...@google.com
Hello
Thank you for your patience.
The Cloud Run Engineering team has confirmed that the issue is fixed now.
Can anyone confirm the same here so that I can mark this issue as fixed? In case the issue still persists please inform here.
be...@funkemedien.de
java.lang.IllegalArgumentException: Invalid IPv4 address: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (example address)
For the test I used the "first" and the "second" Cloud Run execution environment. Same result, the characters "[" and "]" are missing in the header field.
pr...@google.com
Hello,
Thank you for responding.
The Cloud Run Engineering team has confirmed that the changes have been made and it may take upto 2 weeks to take effect. So I would suggest waiting for the next two weeks and after that if the issue still persists then please comment here.
ro...@google.com
pr...@google.com
be...@funkemedien.de
sa...@gmail.com
Successfully tested it again. Works now. Thanks!
co...@onlyonecard.eu
be...@funkemedien.de
se...@d-liver.solutions
se...@d-liver.solutions
ma...@bell.ca
ku...@google.com
Hello,
Thank you for reaching out to us and bringing this to our attention.
The engineering team has been made aware regarding the reoccurrence of this issue. While we cannot provide an estimated time of implementation or guarantee the fulfillment of the issue, please be assured that your input is highly valuable and any further updates will be communicated here.
ba...@google.com
ku...@google.com
Hello,
Update from the engineering team:
The statement in the issue description, "For the X-Forwarded-For header, according to RFC7239, an IPv6 address is always enclosed in square brackets", appears to be a misunderstanding.
Note that IPv6 addresses may not be quoted in X-Forwarded-For and may not be enclosed by square brackets, but they are quoted and enclosed in square brackets in "Forwarded".
Description
Problem you have encountered:
We ran into an issue where our Spring application threw an internal error for one particular person only. That person's connecting device had an Ipv6 address that ended with
:808f.For the
X-Forwarded-Forheader, according to RFC7239,an IPv6 address is always enclosed in square brackets. That did not appear to be the case for the used load balancer on our Cloud Run app (we assumed this by examining the stack traces + respective code of the originating Spring exception) - however we could not fully verify.Since the mentioned header was apparently not enclosed in square brackets, the Spring code mistook the last colon character in the address for a port delimiter. Trying to parse the port as a number then fails in situations where the last Ipv6 part contains any "non-digit" hex character A-F. The
What you expected to happen:
The load balancer should enclose IPv6 addresses in the X-Forwarded-For header in square brackets.
Steps to reproduce:
Deploy a spring boot application on Cloud Run and perform a HTTP request using an IPv6 address that ends with a part containing any hexadecimal characters (A-F, i.e. non-digits).
Other information (workarounds you have tried, documentation consulted, etc):
None.