-
Notifications
You must be signed in to change notification settings - Fork 38.5k
Invalid IPv6 Address with X-Forwarded-For leads to number format exception #26748
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
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Milestone
Comments
I've added a validation resulting in |
rstoyanchev
added a commit
that referenced
this issue
Apr 7, 2021
Avoid DNS resolution. See gh-26748
I am also facing the same issue but failed to find the solution :(. @FlorianLautenschlager @rstoyanchev , do you know the fix to handle ipv6 addresses? |
@sahi1422 no - sorry. We switched to AWS due to customer requirements. Was planned before the issue has occurred. |
lxbzmy
pushed a commit
to lxbzmy/spring-framework
that referenced
this issue
Mar 26, 2022
lxbzmy
pushed a commit
to lxbzmy/spring-framework
that referenced
this issue
Mar 26, 2022
Avoid DNS resolution. See spring-projectsgh-26748
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Affects: Spring Web 5.3.5
Hi Spring Team,
we run our Spring Boot Application using Spring Boot 2.4.4 which includes spring-web-5.3.5 in Google Cloud run.
Every IPv6 address that do not end with only numeric values lead to an internal server error due to a number format exception.
For example, this IPv6 address
2a02:918:175:ab60:45ee:c12c:dac1:808b
leads to a number format exception: as808b
is interpreted as the port. We know that the IPv6 address is invalid due to https://tools.ietf.org/html/rfc7239#section-6 and should be in the format of[2a02:918:175:ab60:45ee:c12c:dac1:808b]
. Therefore we also raised an issue at Google (https://issuetracker.google.com/issues/184230536).Regardless, I wanted to discuss whether better error handling would be useful here:
I would suggest to enforce the format described in RFC-7239 and if not, throw an exception describing the reason.
Kind Regards,
Florian
The text was updated successfully, but these errors were encountered: