true and there are security advantages to have two processes serve 80 and 443 respectively. Let's think about this some more.
On May 14, 7:52 am, Timothy Farrell <tfarr...@swgen.com> wrote: > The only question is: how do you want that to look? > > All web2py interfaces currently only take one IP and socket number. I > don't think it's wise to assume that if someone wants HTTPS they > automatically want HTTP as well (and pick the port for them). You > decide how you want the Tk frontend, the options.py file and the > command-line to handle it and I can adapt those to send it to Rocket. > > My recommendation would be to only change the options file to allow for > multiple interfaces. I'm inclined to think that very few people run > production web2py from the Tk interface. > > -tim > > On 5/13/2010 3:12 PM, mdipierro wrote: > > > Since rocket does it, is there any way we can add support for 80+443 > > with one rocket and one web2py instance? > > > On May 13, 3:02 pm, Timothy Farrell<tfarr...@swgen.com> wrote: > > >> While Rocket supports listening on multiple sockets, web2py does not. > >> You will need to run two separate instances of web2py (one for SSL, one > >> unencrypted) to do what you are asking. > > >> -tim > > >> On 5/13/2010 1:40 PM, Miguel Lopes wrote: > > >>> On Wed, May 12, 2010 at 7:45 PM, Timothy Farrell<tfarr...@swgen.com > >>> <mailto:tfarr...@swgen.com>> wrote: > > >>> This is the error that Jon Lundell's guys found already. Note > >>> that it's trying to connect to port 8000 as HTTP. Connect as > >>> HTTPS and it should work. > > >>> Also try upgrading to trunk, that should issue a "400 Bad Request". > > >>> -tim > > >>> Confirmed. > >>> Updated from trunk to 1.77.3 and if attempting to access the server in > >>> http (instead of https) server issues console warning like you said. > > >>> Since I'm on a LAN I installed SSL as a learning experience and to > >>> access the admin interface anywhere on the LAN. However, now that I > >>> have web2py running with SSL, even the applications must be accessed > >>> via SSL. I expected that only the admin would require SSL. Is this > >>> also a matter of configuration or is there some other reason? I do > >>> have very little knowledge on networks and deployment in general. So I > >>> wonder what is the reason. > > >>> Miguel
