in reply to PSGI, Plack et.al.

HTTP::Server::PSGI there is no information concerning SSL

I'm just saying, as a general rule, if HTTP::Server::PSGI doesn't say it supports HTTPS, it probably doesn't

But, anything Plack/PSGI related probably does support SSL -- if you ask the author I'm sure he'll update the FAQ/docs with an example

When you look at the code you can get the idea that this server is SSL capable. (Is starman SSL enabled?)

Seeing how its a subclass of Net::Server, and there exists Net::Server::Proto::SSL, it probably is

starman ssl_key_file -> http://wiki.catalystframework.org/wiki/deployment/perlbal-starman-psgi

update: plackperl ssl -> http://www.slideshare.net/miyagawa/deploying-plack-web-applications-oscon-2011-8706659 

HTTP::Server::PSGI
• Plack Built-in
• Pure Perl
• Single-process, cross platform
• Experimental IPv6, SSL
• Automatic reloading with -r

plackup https -> Gepok - PSGI server with built-in HTTPS support, Unix sockets, preforking

Replies are listed 'Best First'.
Re^2: PSGI, Plack et.al.
by McA (Priest) on Oct 24, 2012 at 14:09 UTC

    Thank you, Anonymous Monk.

    The last hint was helpful. I'll have a look at Gepok. It seems promising.

    Update: I looked at it and as far as I can see it fulfills exactly what I want for development. Therefor a ++ to our Anonymous Monk.

    Best regards
    McA

[reply]

      I really like Gepok. For Starman etc the advice is to place an HTTPS proxy (e.g. Apache) in front of the server. However, that means that the server misses out on all the transactional information in the HTTPS connection, such as client certificates. Gepok has the HTTPS built in, so you can use HTTPS certificates for authentication.

      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
[reply]

        However, that means that the server misses out on all the transactional information in the HTTPS connection, such as client certificates.

        Sounds fishy, it doesn't look from the docs like Gepok does anything more than Perlbal in terms of ssl suport

[reply]
Re^2: PSGI, Plack et.al.
by Anonymous Monk on Oct 24, 2012 at 19:10 UTC
    Actually, it does not matter. HTTP or HTTPS, the underlying protocol is exactly the same. In Apache, a different <virtualHost> definition will correspond to each. What each one of them does, if need be, could be exactly the same. (If the FastCGI servers are static, the traffic from both VHosts could in fact be sent without error to the same pool. So it CAN be done, should you actually want to do it, and the Perl code does not have to know or care.
[reply]

      Hi,

      but you should not forget that there are circumstances where you want to know whether requests came via https or http. Just two examples:

      • You want to generate absolute URL in the response to reflect the currently used protocol.
      • You want to set the secure attribute on cookies when you know that the response is sent via https.

      Best regards
      McA

[reply]

        A common? trick to avoid the protocol is a schemaless URL:

        # Instead of
https://example.com/foo/bar
# use
//example.com/foo/bar

        [download]

        This will use the same protocol as the origin.

[reply]
[d/l]
        there are circumstances where you want to know whether requests came via https or http

        At least the Apache webserver sets up several CGI environment variables, the most obvious one is HTTPS set to on. It also adds a ton of environment variables starting with SSL_ describing many aspects of the SSL connection. The CGI 1.1 RFC 3875 leaves HTTPS unspecified, but allows the Apache behaviour.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom