First of all, I am sorry that I messed up with your usual process. Please delete the Pull-Request, so that everything goes the right way. It was not my intention to make troubles.
Now about the topic. We want to run the guacamole-client in an Azue Web Service. That is a Service where MS provides everything up to the Tomcat-Server as a Service. You just have to place the war-File on the right position.
It is working fine so far. But one of the issues is that the “X-Forwarded-for”-Header which is forwarded to the guacamole-client contains also the Source-Port number. Because of that only the Tomcat-Server-IP is shown in the History of the guacamole-client. According the REGEX in the source file “guacamole/src/main/java/org/apache/guacamole/rest/auth/AuthenticationService.java” the client just can handle Header with IPs only. We thought about the possibility to expand these regexes.
I agree with mike-jumper that everybody should fulfill the standard, which define that only the IP is in this header. We contacted MS, but the thing is, we don’t aspect any “fast” reaction or change on Azure to solve this topic.
I also agree that the change should be well planned, not to screw up something else.
Original Comment from mike-jumper
Both IPV4_ADDRESS_REGEX and IPV6_ADDRESS_REGEX are documented here as matching IP addresses. Altering them such that they also accept port numbers will mean that the documentation becomes incorrect. If the change proposed here is correct, then that documentation needs to be updated to match. However:
Duplicating the same pattern across both IPV4_ADDRESS_REGEX and IPV6_ADDRESS_REGEX is suboptimal. There are other patterns which would be better homes for this change and avoid duplication, but again: modifying something that is essentially named "IP address" and documented as matching IP addresses such that it also matches port numbers isn't complete in itself. That change would need to be followed through such that the documentation and naming are correct.
The de facto X-Forwarded-For header is defined as a list of IP addresses, not a list of IP addresses with optional port numbers:
If there are real world cases where a port number is included, please provide some background information when you open the corresponding issue in JIRA so the reasoning for your proposed change can be understood.