Port-forwarding, httpservletrequest, and a bug caused by negligence

Recently I took over a bug. It is strange that the WebService released by the product does not work and the error "connection refused" is returned.

After checking, all the WebService calls reported by the error come from the server's local machine, that is, the WebService released on the local machine is called in the code of the local machine. It's ugly, but it won't report an error.

After some investigation, we found that the access from the client to the server was not allowed directly, but the request for the public server was mapped to the private server through NAT port-forwarding, not only the IP address was mapped, the port is also mapped, that is, the URL: http: // ip: port called by the client is not the IP address of the Real Server or the port of the HTTP listener, these are the IP and port of the public network machine. After receiving the request, the public network machine maps to the private IP and port.

OK, this is OK, because the part that does not involve calling the WebService on the local machine is normal. After checking the WebService calling method of the local machine in the Code, the following information is found:Code:

 
Servletrequest. getserverport ()
 

What a look at no problem, a careful look really have a problem, the following is the explanation of JAVA-API:

Getserverport public int getserverport () returns the port number to which the request was sent. it is the value of the part after ":" in the Host header value, if any, or the server port where the client connection was accepted on. returns: an integer specifying the port number
 

The returned value is the port in the request URL of the client. As described above, this port is not actually the port of the server but the port of the public network. Ha, the problem was originally found here! So how to fix it?

 
Getlocalport public int getlocalport () returns the Internet Protocol (IP) Port Number of the interface on which the request was received ed. Returns: an integer specifying the port number since: 2.4
 

In the absence of port-forwarding, the two APIs return exactly the same time, but this case is quite different, this also explains why the bug was not found at the factory.

This record has been checked and written in disorder. Any comment please free let me know.