[Devel] Moving the site to https (I just did it, but, um, should we really keep it this way?)

[Raphael Krut-Landau]

Would this work: Move the CRM somewhere else, and redirect https to http?

While you make a good for https not mattering that much, I feel it
would be prudent to avoid, if we can, moving the whole site into
https. The downside is that it's a slightly slower protocol (because
of PermanentRedirects and handshaking) that has more moving parts,
thus slightly higher maintenance costs and more potential ways to
fail. (Possibly this is a very small downside, but it's still a
downside.) And the upsides to https seem small: a slight feeling of
security for our users perhaps, but we use OpenID anyway. Has anybody
asked for https?

On Thu, Dec 3, 2009 at 1:16 AM, Asheesh Laroia <asheesh at openhatch.org> wrote:
> Excerpts from Raphael Krut-Landau's message of Thu Dec 03 06:01:59 +0000 2009:
>> Perhaps this is a stupid question, but is there any upshot for
>> PageRank? For instance: Will Google think that inbound links to
>> http://openhatch.org count less because of the redirect, or something
>> like that?
>
> If we do RedirectPermanent, PageRank will flow. See
> http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=34444
> and its discussesion of RedirectPermanent.
>
> I thought I'd get your OK before making them RedirectPermanents.
>
>> Also, is https measurably slower by any chance? (I'm recalling stats
>> about how milliseconds' difference in page load time can  make all the
>> difference to click through rates.)
>
> I recall those stats too. It'd be nice if we can find them.
>
> It's tough to say. The *first* connection is slower -- two round trips
> become five -- but then every connection after that should be just as
> fast.
>
> http://stackoverflow.com/questions/149274/http-vs-https-performance for
> a little more info.
>
>> Thanks for the detailed report!
>
> No problem.
>
>>
>> --Raffi
>>
>> On Thu, Dec 3, 2009 at 12:36 AM, Asheesh Laroia <asheesh at openhatch.org> wrote:
>> > A problem:
>> >
>> > When you go to https://openhatch.org/, you get a website that isn't
>> > openhatch.org. You get our fruity CRM thing (which we want to stop using
>> > anyway).
>> >
>> >        An obvious solution:
>> >
>> >                Make the https site have the same configuration as the
>> >                main site.
>> >
>> >        Downside:
>> >
>> >                Apache will run the Python processes twice. This doubles
>> >                the memory load on the server, and we discovered before
>> >                that it can't take it.
>> >
>> >        A second, similar obvious solution:
>> >
>> >                Use mod_proxy. Apache has a built-in system for
>> >                "proxying" HTTP requests. This means, whenever someone
>> >                hits https://openhatch.org/, the *web server* on the
>> >                linode *itself* does a GET of http://openhatch.org/, and
>> >                returns that page to the person who asked for https.
>> >
>> >        A different downside:
>> >
>> >                Now when Django sees a request, it only ever sees a
>> >                request as given to it by the *web server*, not a real
>> >                client. This means everyone's IP address is 127.0.0.1.
>> >
>> >                That's pretty broken. It can be worked-around (there's
>> >                a header called X-Forwarded-For) but it requires
>> >                fiddling and no one's ever too happy relying on that
>> >                header.
>> >
>> >        The solution I've come up with:
>> >
>> >                Migrate everyone to https://openhatch.org/. That way,
>> >                we can mumble things about "protecting our users'
>> >                privacy". (Note that ohloh.net does this, too, and a few
>> >                other sites (Launchpad I think?) also do.)
>> >
>> >                Also, it's easy to configure and doesn't cause extra
>> >                load. It also eliminates the confusion where /bugs/ is
>> >                on https (because it uses passwords) but / is not.
>> >
>> >                "Migrate everyone" is implemented as "Requests to
>> >                http://openhatch.org/ cause a redirect to
>> >                https://openhatch.org/".
>> >
>> >        The downside:
>> >
>> >                Not much, really. Possibly a few random internal links
>> >                will link to http://openhatch.org/something/ and they
>> >                will cause the user redirects.
>> >
>> >                Also, SSL negotiation will necessarily cause a few
>> >                extra round-trips. That will increase latency, I'm
>> >                afraid, which is experienced as slightly higher
>> >                page-load times.
>> >
>> > Raffi, if you're okay with this "everyone on https", then I should
>> > change our Apache confguration so it's a "RedirectPermanent" not a
>> > "Redirect". That way, search engines will update their canonical URLs.
>> >
>> > -- Asheesh.
>> >
>> > --
>> > Good day for overcoming obstacles.  Try a steeplechase.
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at lists.openhatch.org
>> > http://lists.openhatch.org/mailman/listinfo/devel
>> >
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>