You can get the socket from Nitrogen and from the socket determine its type:
In code that could be something like
is_ssl() ->
Socket = wf:socket(),
is_tuple(Socket) andalso element(1,Socket)=:=sslsocket.
Though I personally prefer to throw nginx in front of Nitrogen deal
with that kind of routing (URL-based, anyway).
-Jesse
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Thank you! That sounds like just what I need. I didn't realise wf:socket()
would tell me the socket type--very useful!
I am actually using Apache as a reverse proxy to forward port 80 to 8000
already... my problem is I want to access the *same page* (i.e. same .erl
file) through http and https, and see different options in each case. I
suppose I could make two different pages, but that would be more complex and
less maintainable however I did it (code duplication or a more complex
module structure). I'm not sure nginx would really solve that problem for
me.
John
Depends where you want routing decisions to be handled. In front
webserver (nginx) or in Erlang application?
If in a-la-nginx, simply configure access rules for both http and
https virtualhosts individually.
If nitrogen case, I would think about doing the Erlang application on
a single http port, and using a real web server to make "real" 80 and
443. And append some kind of header in each case (X-port: 80/443 for
instance).
I don't know the exact syntax for web servers, but should be easy to
figure it out.
Motiejus Jakštys
Further, if you need to find out if the client is connecting with ssl, you can add an nginx (or apache) rule to add a custom header for clients connecting through ssl, then check for the existence of the header in nitrogen.
The main reason I'd do that is to minimize the number of servers with the ssl cert installed. Though in the long run, for performance, you can switch all static files to be served from nginx/apache, and leave all the dynamic stuff to nitrogen/inets.
But if this isn't exactly a high performance app, then most of this of overkill anyway.
--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866
www.sigma-star.com
@jessegumm