<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Opa Stainislaw!<div><br></div><div>Belo ponto, uma das coisas que ouvi enquanto testava foi:<br>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

"quando mando um request, o segundo programa não funciona"</blockquote></div><div>traduzindo seria algo como:</div><div><i>o segundo request fica esperando até que o primeiro complete-se.</i></div><div><br></div>

<div>A equipe da empresa que estou é formada por Eu (que aprendi linux "na marra" e não sei nada muito avançado, por exemplo, sei o que é iptables, mas nem pense eu dizer para eu edita-lo), um outro programador .not (C#) e um especialista em marketing metido<i> (mas ele é legal) </i>a sysadmin!</div>

<div><br></div><div>Então ele que "resolve" esses problemas de certificados e rotas dos firewalls/hardware.</div><div><br></div><div>Eu sempre tento acompanhar ele para aprender essas coisas, mas nem sempre é possível.</div>

<div>Escrevi tudo isso para dizer que nem eu, nem ele, sabemos configurar um <span style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">lighttpd com a mesma facilidade do apache.</span></div>

<div><font face="arial, sans-serif"><span style="border-collapse: collapse; ">Não que isso seja um impedimento, pois se necessário, iremos pesquisar como!</span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse; "><br>

</span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse; ">Mas por um futuro, tomara que não longo, não temos nem banda, nem processadores para 10k de coneções!</span></font></div><div>

<font face="arial, sans-serif"><span style="border-collapse: collapse; "><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse; ">Quando chegar o certificado, vou testa-lo via FastCGI com apache, pois já resolve o problema do "lock"</span></font></div>

<div><font face="arial, sans-serif"><span style="border-collapse: collapse; "><br></span></font></div><div><font face="arial, sans-serif"><span style="border-collapse: collapse; ">Temos muitas coisas para mudar na estrutura para podemos crescer escaladamente</span></font></div>

<div><font face="arial, sans-serif"><span style="border-collapse: collapse; "><br></span></font></div><div>Lorn,</div><div><br></div><div>Ufa! que bom saber que pelo menos meu raciocínio que o HTTPS é transparente para o HTTP.</div>

<div><br></div><div>Agora é esperar pela compra, e testar.</div><div><br></div><div>O Eduardow achou o HTTP::Daemon::SSL, mas cairia no mesmo "BUG" do lock, e o FastCGI é uma melhor opção!</div><div><br></div><div>

<br></div><div>obs para lista: houve trocas de e-mails internas, então esta msg pode conter textos no tempo errado!</div></span><br><div class="gmail_quote">2011/3/16 Stanislaw Pusep <span dir="ltr"><<a href="mailto:creaktive@gmail.com">creaktive@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Aliás, me lembrei do AnyEvent::HTTPD, uma alternativa ao HTTP::Daemon. Ele atende a múltiplas conexões simultâneas (não chega a C10k, rsss), e acabei de ver que implementa HTTPS!<div>

<br></div><div><div><font face="'courier new', monospace" size="1">my $httpd =</font></div>

<div><font face="'courier new', monospace" size="1">   AnyEvent::HTTPD->new (</font></div><div><font face="'courier new', monospace" size="1">      port => 443,</font></div>

<div><font face="'courier new', monospace" size="1">      ssl  => { cert_file => "/path/to/my/server_cert_and_key.pem" }</font></div><div><font face="'courier new', monospace" size="1">   );</font></div>



<br>ABS()<div><div></div><div class="h5"><br><br>
<br><br><div class="gmail_quote">2011/3/16 Lindolfo Lorn Rodrigues <span dir="ltr"><<a href="http://lorn.br" target="_blank">lorn.br</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Você pode continuar usando o seu codigo, e o HTTP::Daemon apensar colocando um Nginx na frente ( o nginx trataria todos os problemas de SSL ) e faria o proxy para o seu codigo HTTP::Daemon na porta 8029 transparentemente.<div>



<div></div><div><br>
<br><div class="gmail_quote">2011/3/16 Stanislaw Pusep <span dir="ltr"><<a href="mailto:creaktive@gmail.com" target="_blank">creaktive@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




Renato, creio que seria mais robusto colocar um servidor HTTP "parrudo" entre a Internet e o daemon em Perl. Argumento: HTTP::Daemon dificilmente trata do C10k (<a href="http://en.wikipedia.org/wiki/C10k_problem" target="_blank">http://en.wikipedia.org/wiki/C10k_problem</a>). Não que seja crítico, mas é meio que bom-senso, do ponto de vista da escalabilidade :)<div>






Um servidor HTTP extremamente leve e aonde configurar FastCGI é ridiculamente simples é o lighttpd. Veja a documentação do uso do HTTPS com lighttpd: <a href="http://redmine.lighttpd.net/wiki/lighttpd/Docs:SSL" target="_blank">http://redmine.lighttpd.net/wiki/lighttpd/Docs:SSL</a></div>






<div>Já para habilitar o FastCGI, é *SÓ ISSO*:</div><div><br></div><div><font face="'courier new', monospace" size="1">server.modules = (</font></div>

<div><div><font face="'courier new', monospace" size="1">    "mod_fastcgi",</font></div><div><font face="'courier new', monospace" size="1">)</font></div>

</div><div><font face="'courier new', monospace" size="1"><br></font></div><div><font face="'courier new', monospace" size="1"><a href="http://redmine.lighttpd.net/wiki/lighttpd/Docs:SSL" target="_blank"></a></font><div>






<font face="'courier new', monospace" size="1">fastcgi.server = (</font></div><div><font face="'courier new', monospace" size="1">    "" => (</font></div>

<div><font face="'courier new', monospace" size="1">        "webapp" => (</font></div><div><font face="'courier new', monospace" size="1">            "host"          => "127.0.0.1",</font></div>






<div><font face="'courier new', monospace" size="1">            "port"          => 55900,</font></div><div><font face="'courier new', monospace" size="1">        )</font></div>

<div><font face="'courier new', monospace" size="1">    )</font></div><div><font face="'courier new', monospace" size="1">)</font></div><div><br></div><div>

ABS()<br><br>
<br><br><div class="gmail_quote"><div><div></div><div>2011/3/16 Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div><div></div><div>

<div>Olá Perlssoas,</div><div><br></div><div>Estou precisando (na realidade, vou precisar) de ajuda para fazer uma troca de HTTP para HTTPS.</div><div><br>

</div><div>Estou utilizando o modulo<b> HTTP::Daemon </b>para criar um servidor (um servidor RPC2 XML usando o modulo <b>Frontier::RPC2</b>) </div><div>que fica esperando por coneções na porta 8029 (mas pode ser 'qualquer uma'!)</div>








<div><br></div><div>Pelo que entendo, o HTTPS é um "tunel" seguro, e, mesmo que passe por vários lugares, ninguém até o servidor (ou cliente, na 'volta') sabe o conteúdo.</div><div>Quando o <i>Request</i> é entregue no servidor <i>(servidor como software [ex: apache, serviço perl]) </i>e que o conteúdo é descriptografado e lido por algum programa, que executa o que estiver programado pelo resquest.</div>








<div><br></div><div>A pergunta mais simples que posso fazer, é, vamos comprar está certificação aqui:</div><a href="http://www.certisign.com.br/produtos-e-servicos/certificados-para-servidor-web/certificado-para-servidor-web-icp-brasil" target="_blank">http://www.certisign.com.br/produtos-e-servicos/certificados-para-servidor-web/certificado-para-servidor-web-icp-brasil</a><div>








<br></div><div><a href="http://www.certisign.com.br/produtos-e-servicos/certificados-para-servidor-web/certificado-para-servidor-web-icp-brasil" target="_blank"></a>Podemos utiliza-la, certo?</div><div><br></div><div>E a segunda pergunta é, como mudo o <b>HTTP::Daemon</b> para HTTPS?</div>








<div>Lendo a pagina2(instalando o certificado no apache openssl)* presumo que o HTTPS só vai ficar disponivel para as coneções que passarem pelo apache.</div>

<div><br></div><div>Então, terei que criar alguma forma de executar o codigo pelo apache, pode ser então via mod_php, mod_perl, mod_fcgid onde o request( header+content) chegará limpo (sem criptografia) e o que eu devolver, será criptografado e entregue.</div>








<div><br></div><div>* pagina2: <a href="http://www.certisign.com.br/suporte/procedimentos/instalacao-do-certificado-apache-openssl/instalando-o-certificado-no-apache-openssl" target="_blank">http://www.certisign.com.br/suporte/procedimentos/instalacao-do-certificado-apache-openssl/instalando-o-certificado-no-apache-openssl</a></div>








<div><br></div><div>Eu posso usar um outro servidor, como por exemplo <span style="font-family:Courier;font-size:14px;white-space:pre-wrap"><b>Mojolicious::Lite </b></span>  mas eu sei que isso é uma parte transparente, e talvez me sirva, se eu alterar a pasta para executar com fast_cgi</div>








<div><br></div><div>Peço a ajuda de vocẽs para me clarear as idéas, pois nunca fiz nada com HTTPS, e gostaria de ajuda</div><div><br></div><div>Podem xingar se não entenderam alguma coisa! Eu explico de outro modo!</div>







<div>
<div><br>-- <br>Renato Santos<br><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>
</div></div>
<br></div></div>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><br></div></div>-- <br>lorn at lornlab dot org<br><font color="#888888">Lindolfo "Lorn" Rodrigues<br><br>
</font></blockquote></div><br></div></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Renato Santos<br><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>