The new code uses the sockaddr as returned by the sock.getsockname() to determine which handler to use. The getsockname is returning a number which has already been truncated into the 16 bit value.
The old code did no such thing, and only did a getsockname() comparison for the monitor port (which would have failed if the monitor port was > 64k). If it wasn't the monitor port then it assumed it to be the app server.
My guess is that for this to have worked, nobody was doing a range check on the port in the past, and it was just silently getting mapped into the 16 bit value.
-Stuart -
Chuck Esterbrook wrote:
On Sunday 30 March 2003 05:37 pm, Ian Bicking wrote:On Sun, 2003-03-30 at 18:48, Chuck Esterbrook wrote:On a hunch, I changed the port from its original value of 80000 to 9999 and now it works. I then reversed the situation: I installed fresh copies of Apache and WebwareCVS, got them working, then pumped up the port # to 70001 and got this:KeyError: ('127.0.0.1', 4465) Looks like a classic case of 16bit vs 32bit. I thought those days were over! :)That's just the way it is, there's 65k ports, no more. It should never work, though confusingly it seems to be just cutting off the high bits. I suppose there should be an assert somewhere to make sure you don't try anything too large. IanPort 80000 worked for almost 3 years and stopped working under the new ThreadedAppServer.py just ten days ago. That belies "there's 65k ports, no more". I'm guessing that a library used by the new code is arbitrarily chopping things off. It's not the end of the world, but it's unfortunate that some libraries still "exist in a 16-bit world".
