Home / server / Questions / 16829
Accepted
Robert Deml
Asked: 2009-06-02 06:04:38 +0800 CST

What happens to httpd when it is given a bad port number?

  • 772

I have a httpd.conf file that was accidentally changed to have the port number the server listens on changed to a number higher than 65535. When HTTPD reads this configuration file what does it do? Does it fall back to port 80?

port configuration httpd

4 Answers

  1. Best Answer

    It depends on the configuration. You can define multiple ports to listen on, in which case it will attempt to bind to all of them. Think of the application startup as a multiple step process. In it's most basic form the process would look like this:

    1. Read the config file, checking for errors
    2. Attempt to bind to the specified port
    3. Listen for connections

    If you give it an unusable, but existing, port, then httpd would hit step 2 and fail. The application would fail to completely start, and would not fail down to port 80.

    In the case where you presented a non-port, that is text, negative number, or number higher than 65535, then the config would be considered invalid, and httpd would die at 1.

    • 5

  2. One way would be to try it yourself, and use 

    netstat -lptn
    to see what port httpd is listening on.

    • 2

  3. If you set the port higher than 65535, say for example 65536, it will give a syntax error saying "Invalid Address or Port".

    • 1

  4. A lot depends on the specific server software you're using.

    You would expect the software to throw an error over an illegal port number but that is not necessarily the case; some software will happily accept whatever you hand it, resulting in very odd behavior.

    Here's the issue: The port number is an unsigned 16-bit value (0 - 65535) and in some situations, applications will accept larger numbers but only use the lower 16 bits. This has lead to baffling cases where a startup script specifies a port of (say) 90000 and the application is found listening on port 24464 (90000 mod 65536 = 24464)

    I documented a similar incident back in the Feb 2002 issue of SysAdmin Magazine in "Increasing Reliability Through Forensic Operations" (copy) Ideally, these things should never happen but between naive software and developers ignorant of the specifics of the underlying network (i.e. range of legitimate ports) one still needs to guard against such 'impossible' incidents. My preferred approach is to work with developers to make sure their code is ops-friendly but often ops and development aren't on the best of terms.

    • 0