Reported by rbrewer, Aug 19, 2012
Applications on Heroku are expected to bind to a port on the interface where they are running, and this private & dynamic port is provided to the application via the $PORT environment variable. Heroku's routing infrastructure then routes connections on the standard port 80 to the application running on that private port. So the application is binding to the private & dynamic port, but any external client must send requests to port 80.
Unfortunately, WattDepot's underlying assumption is that the configured port is used both for binding and for connections from clients. This causes problems because the port number is used in at least 3 places: by the Server to decide what port number to bind to (on Heroku this is the private port # given by the $PORT environment variable), the announced URL of the server to the public (always 80 on Heroku, though usually left out of URI to default to 80), and the URI of parent resources such as a Source in a SensorData resource (should be
the public port on Heroku). If the URI given inside the SensorData resource does not match the URI used in the PUT of the resource, WattDepot will complain.
This is confusing and requires kludges like a special case in the ServerProperties.getFullHost() method. These two concepts should be separated for Heroku: the private port which is only used to bind the Server, and the public port, which is always 80.
Reported by rbrewer, Aug 19, 2012 Applications on Heroku are expected to bind to a port on the interface where they are running, and this private & dynamic port is provided to the application via the $PORT environment variable. Heroku's routing infrastructure then routes connections on the standard port 80 to the application running on that private port. So the application is binding to the private & dynamic port, but any external client must send requests to port 80.
Unfortunately, WattDepot's underlying assumption is that the configured port is used both for binding and for connections from clients. This causes problems because the port number is used in at least 3 places: by the Server to decide what port number to bind to (on Heroku this is the private port # given by the $PORT environment variable), the announced URL of the server to the public (always 80 on Heroku, though usually left out of URI to default to 80), and the URI of parent resources such as a Source in a SensorData resource (should be the public port on Heroku). If the URI given inside the SensorData resource does not match the URI used in the PUT of the resource, WattDepot will complain.
This is confusing and requires kludges like a special case in the ServerProperties.getFullHost() method. These two concepts should be separated for Heroku: the private port which is only used to bind the Server, and the public port, which is always 80.