Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request - Missing SPDY support in Apache default configuration #262

Closed
OnePressTech opened this issue Sep 28, 2014 · 9 comments
Closed

Comments

@OnePressTech
Copy link

To improve performance of the TKLX server it is suggested that SPDY be enabled by default. Caveat: It would need to be verified first that there would be no negative impacts on http-based websites run off the same Apache server. Google is giving SEO priority to SSL-based sites moving forward so it could be reasonably expected that TKLX should support better performance for SSL-based websites out of the box subject to there being no side-effects on http-based websites.

@JedMeister
Copy link
Member

TBH I hadn't heard of SPDY before so I just did a little research. So having just done a bit of reading about SPDY my personal preference would be to have some documentation about installing and enabling it (maybe a blog post?) rather than having it set up by default.

There are a couple of elements to my argument for that but they basically boil down to:

1 - Debian do not have a SPDY package in the repos (so we'd have to add a 3rd party repo to almost all TKL appliances by default - not something I'd be that keen about).

2 - SPDY for Debian is currently only available in a beta version (I couldn't get full clarity on this and is only an assumption made from the package name 'mod-spdy-beta_current_amd64.deb', please feel free to correct me if I'm wrong).

3 - From what I have read, when you initially install it (by downloading the deb and installing with dpkg), it adds the google repo to your sources.list, but it wouldn't be added to auto security updates. Obviously we could manually configure that, but considering that (from info I could find) the repo only provides updated version (not backported security patches as per Debian security) I would be hesitant to do that.

I am certainly open to being persuaded that I am wrong and have overlooked or not considered some other aspects, but considering that currently only ~1% of websites use SPDY (according to Wikipedia) it's still only a 'nice to have' rather than a 'have to have'.

References/links of interest:
http://en.wikipedia.org/wiki/SPDY
https://code.google.com/p/mod-spdy/
https://developers.google.com/speed/spdy/mod_spdy/
http://www.howtoforge.com/using-mod_spdy-with-apache2-on-debian-squeeze
https://www.digitalocean.com/community/tutorials/how-to-install-apache-mod_spdy-on-a-debian-7-vps

@OnePressTech
Copy link
Author

You are correct on all fronts. The reason I added this as a feature enhancement was primarily to put it on yours, Liraz's and Alon's radar.

With the recent outbreak of hacking of big-name sites triggering a move to "all ssl" the writing is on the wall for TKLX users to need to support "all ssl". An example is Google's statement that they will provide a SEO boost to ssl-enabled websites (http://googlewebmastercentral.blogspot.com.au/2014/08/https-as-ranking-signal.html ).

My second reason for putting it in as a feature enhancement is that, although Debian Apache is slow off the mark with SPDY, NGINX has had it in play since inception and it is available in the wheezy backports (see https://packages.debian.org/wheezy-backports/s390x/nginx-extras ).

It would be reasonable to have spdy auto-configured in the Nginx PHP FastCGI Server appliance...subject to it not having side-effects for a non-ssl deployment of the Nginx PHP FastCGI Server appliance.

@OnePressTech
Copy link
Author

This Github choice of Comment / Close & Comment button gets me every time...I keep thinking the choice is to close the comment...not close the issue!

@JedMeister
Copy link
Member

Hehe, yeah I agree, close the comment, not the issue! :)

Seeing as Nginx has SPDY available in Wheezy backports - that is an entirely different matter (and one that I didn't research). I would certainly be supportive of Nginx being set to use SPDY as default over SSL (and assuming that your note regarding not interfering with non-SSL could also be met).

@JedMeister
Copy link
Member

Hey Tim... Have you seen this:
http://techcrunch.com/2015/02/09/google-starts-fading-out-spdy-support-in-favor-of-http2-standard/

So perhaps HTTP/2 instead of SPDY !?
I haven't yet had time for any research on HTTP/2 yet but it does seem silly to implement SPDY support when browsers are going to stop supporting it.

Thoughts?

@OnePressTech
Copy link
Author

Hey Jeremy. Thanks for the heads up. I hadn’t seen that. http/2 won’t make it into the next TKLX release which I would expect will be based on Jesse so SPDY will be the way to go for now.

SPDY3.1 made it into NGINX 1.6 (https://packages.debian.org/jessie/nginx-full ) and subsequently Jessie ( https://packages.debian.org/jessie/nginx-full )

Apache2.4 made it into Jessie (https://packages.debian.org/jessie/apache2 ) and Google donated mod_spdy to apache.org to include in apache2.4 (http://thetrendythings.com/read/6340 ). It is possible mod_spdy made it into a core release of apache2.4 (https://svn.apache.org/viewvc/httpd/mod_spdy/ ) but it may not have…in which case it would need to be installed by TKLX as a 3rd-party plug-in if the less technical TKLX users are to benefit out-of-the-box.

Just a thought J

From: Jeremy Davis [mailto:notifications@github.com]
Sent: Tuesday, 10 February 2015 1:39 PM
To: turnkeylinux/tracker
Cc: OnePressTech
Subject: Re: [tracker] Feature Request - Missing SPDY support in Apache default configuration (#262)

Hey Tim... Have you seen this:
http://techcrunch.com/2015/02/09/google-starts-fading-out-spdy-support-in-favor-of-http2-standard/

So perhaps HTTP/2 instead of SPDY !?
I haven't yet had time for any research on HTTP/2 yet but it does seem silly to implement SPDY support when browsers are going to stop supporting it.

Thoughts?


Reply to this email directly or view it on GitHub #262 (comment) . https://github.com/notifications/beacon/AFIKhIIivOMJKIR5GDC_gHOJp22e5Yu3ks5nqWa-gaJpZM4CoKcz.gif

@JedMeister
Copy link
Member

As per usual; great research and fantastic analysis! Thanks! 👍

@JedMeister JedMeister added this to the 14.0 milestone Jul 14, 2015
@a3s7p
Copy link
Member

a3s7p commented Aug 16, 2015

mod_spdy is only officially supported for Apache 2.2. For Apache 2.4 an unofficial port exists. It is not actively maintained. It does not support SPDY/3.1, which is the only version Google Chrome/Chromium supports. Google are phasing out support for SPDY completely by early 2016 in favor of HTTP/2.

The nginx mod does support v3.1 (and Nginx serves 95% of all websites that are served via SPDY), but as the bulk of TKL appliances use Apache as the webserver (about 5 use nginx), I doubt this feature is not a dead end.

There is a preliminary alpha mod_h2 for Apache. It is not yet production-ready.

The nginx version of HTTP2 is in alpha, too.

I am convinced the best way to go about this is to leave SPDY alone and wait until major webserver upstreams catch up with the HTTP2 standard towards the end of 2015. If it ain't broke, don't fix it.

cf. https://serverfault.com/questions/660735/apache-httpd-with-spdy-3-1

@JedMeister
Copy link
Member

Thanks @qrntz for having a look at this. I am inclined to agree with you so am closing for now. @OnePressTech if you have objections please feel free to update/add-to/reopen/etc this issue! 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants