Support Apache 2.4

[GoogleCodeExporter]

mod_spdy currently only works for Apache 2.2.  We should make it also available 
for Apache 2.4.

Original issue reported on code.google.com by mdste...@google.com on 28 Jan 2013 at 3:09

[GoogleCodeExporter]

Issue 63 has been merged into this issue.

Original comment by mdste...@google.com on 28 Jan 2013 at 3:13

[GoogleCodeExporter]

Agreed.  Our goal has always been to use the current version of everything we 
have installed on our servers.  We're using Apache 2.4.3 (current) with php 
5.4.11 (current) and MySQL 5.6 (current).  And as soon as php 5.5 comes out (in 
beta now) we'll upgrade to that as well.

The only thing missing is Google.

Original comment by Oldschoo...@gmail.com on 8 Feb 2013 at 7:44

[GoogleCodeExporter]

Issue 65 has been merged into this issue.

Original comment by mdste...@google.com on 13 Feb 2013 at 4:06

[GoogleCodeExporter]

What is actual status of issue? I'd like to use spdy on our 2.4. Thank you.

Original comment by d.ok...@gmail.com on 10 Apr 2013 at 9:37

[GoogleCodeExporter]

Hello!

I managed to make mod_ssl with NPN support and mod_spdy work with Apache 2.4, 
it just needs a couple of changes in the source code.
Here is the general idea (iterative process) how I did it:
(If someone is wondering, my box is a Hardened Gentoo amd64 no-multilib system, 
with 3.7 hardened kernel (grsecurity), hardened gcc 4.5 (pie, ssp), kernel is 
non-modular and without ia32 support.)
- I expect you already have a working apache setup with https: site(s) and 
valid certificate(s), and know how to configure apache itself.
- Installed depot_tools ( 
http://dev.chromium.org/developers/how-tos/install-depot-tools ). Didn't have 
git installed, so I installed it: 
dev-vcs/git[blksha1,curl,iconv,nls,pcre,threads,webdav]
- depot_tools doesn't mention it needs Python 2 (incompatible with Python 3), 
so I had to get it too: 
dev-lang/python:2.7[examples,gdbm,hardened,ipv6,ncurses,readline,ssl,threads,wid
e-unicode,xml]
- I didn't wanted to add it to PATH, so I just invoked it as 
~/depot_tools/gclient
- Following 
http://code.google.com/p/mod-spdy/wiki/GettingStarted#1._Get_the_code
- Noticed running "~/depot_tools/gclient sync --force" sometimes exits 
abruptly, repeating the command - till there is no error message at exit - 
checks out everything (Error retrieving REPORT (X): APR does not understand 
this error code)

- After checking out, you can apply my patch to make the changes to the source 
this guide describes:

$ cd src
$ patch -p1 < 2.2_to_2.4.diff

You still need to change the apache configuration yourself.

- The second chapter tells us to run (don't yet, if you didn't apply the patch 
above!) build_modssl_with_npn.sh to build mod_ssl with NPN support. It uses 
OpenSSL 1.0.1c and Apache 2.2.22. We actually want it to work with 2.4.4, so we 
need to edit this file:
0. Check the 35th line. It says if we supply a BUILDROOT environment variable, 
it will use that as a compile space, instead of tmp, and it will not remove it 
after the compilation. This will come handy in a moment.
1. On the 97th line, you can see it tries to download httpd-2.2.22.tar.gz file. 
Modify the version to 2.4.4 .
2. On the 116th line, you can see the MD5 sum of the httpd tar.gz file, if it 
doesn't match, it will throw away the file, so we need to modify it: Addig .md5 
to the URL gives that back: 
http://archive.apache.org/dist/httpd/httpd-2.4.4.tar.gz.md5 , which will give 
us a2fed766e67c9681e0d9b86768f08286 , replace the old one to that.
3. Now we can try to run it (it will fail, but we can continue after that):
$ mkdir mod_ssl
$ BUILDROOT=mod_ssl ./build_modssl_with_npn.sh
Using buildroot: /home/wilyfox/mod_spdy/mod/mod_ssl

Downloading http://www.openssl.org/source/openssl-1.0.1c.tar.gz
######################################################################## 100,0%
Downloading http://archive.apache.org/dist/httpd/httpd-2.4.4.tar.gz
######################################################################## 100,0%

Uncompressing openssl-1.0.1c.tar.gz ... done
Uncompressing httpd-2.4.4.tar.gz ... done
Applying Apache mod_ssl NPN patch ... patching file modules/ssl/ssl_private.h
Hunk #1 succeeded at 614 with fuzz 2 (offset 11 lines).
patching file modules/ssl/ssl_engine_init.c
Hunk #1 succeeded at 725 with fuzz 1 (offset 166 lines).
patching file modules/ssl/ssl_engine_io.c
Hunk #1 succeeded at 297 (offset -41 lines).
Hunk #2 succeeded at 1386 (offset -24 lines).
Hunk #3 succeeded at 1888 with fuzz 1 (offset 113 lines).
patching file modules/ssl/ssl_engine_kernel.c
Hunk #1 FAILED at 2104.
1 out of 1 hunk FAILED -- saving rejects to file 
modules/ssl/ssl_engine_kernel.c.rej
patching file modules/ssl/mod_ssl.c
Hunk #1 succeeded at 272 (offset 52 lines).
patching file modules/ssl/mod_ssl.h
Hunk #1 succeeded at 63 with fuzz 2 (offset 3 lines).
can't find file to patch at input line 224
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: modules/ssl/ssl_toolkit_compat.h
|===================================================================
|--- modules/ssl/ssl_toolkit_compat.h   (revision 1367982)
|+++ modules/ssl/ssl_toolkit_compat.h   (working copy)
--------------------------
File to patch: 

4. Hit Ctrl+C to abort patching. In the mod_ssl folder, you will see a 
mod_ssl_npn.patch, (which actually originates from 
scripts/mod_ssl_with_npn.patch in the src folder).
5. Delete the httpd-2.4.4 folder, and uncompress the httpd-2.4.4.tar.gz again 
(to revert the half-applied patch; actually it would be enough to delete the 
contents of the modules/ssl folder and uncompress only that)
$ cd mod_ssl
$ rm -r httpd-2.4.4
$ tar xzvvf httpd-2.4.4
6. Now we try to modify the mod_ssl_npn.patch file, to make it work:
As we can see from the previous run, ssl_engine_kernel.c failed. Examine that 
portion of the file (starting at line 77). The entry actually adds a new 
function, does nothing else.
The problem is in 2.4 modules/ssl/ssl_engine_kernel.c got extended (added SRP 
support), so the end of the file does not match.
The fix is simple, copy the last 3 lines of the file, and replace the ones 
between the @@ and the + lines. Dont forget to add one space to the start of 
each line after pasting.
We can still see an error, modules/ssl/ssl_toolkit_compat.h does not exist 
anymore. To get a clue which file needs to get patched, check the contents of 
the change in the patch file (starting at line 220).
We see the unmodified original context, #define HAVE_FIPS before, and #ifndef 
PEM_F_DEF_CALLBACK after. Let's search for a file which has "#define 
HAVE_FIPS"! This gives us only one file: modules/ssl/ssl_private.h, line 139. 
Check the file.
We found the prefix of the patch, now search for the suffix. We can find that a 
few line later, at 152. We can see there is an extra block inside that file, 
that will be no problem for us (the new code is ok either before or after it).
So edit the patch again, and modify filename three places (from 
ssl_toolkit_compat.h to ssl_private.h in lines 220, 222 and 223).
7. We can try if the patch would apply now or not:
$ patch --dry-run -p0 -d httpd-2.4.4 < mod_ssl_npn.patch
patching file modules/ssl/ssl_private.h
Hunk #1 succeeded at 614 with fuzz 2 (offset 11 lines).
patching file modules/ssl/ssl_engine_init.c
Hunk #1 succeeded at 725 with fuzz 1 (offset 166 lines).
patching file modules/ssl/ssl_engine_io.c
Hunk #1 succeeded at 297 (offset -41 lines).
Hunk #2 succeeded at 1386 (offset -24 lines).
Hunk #3 succeeded at 1888 with fuzz 1 (offset 113 lines).
patching file modules/ssl/ssl_engine_kernel.c
Hunk #1 succeeded at 2186 (offset 82 lines).
patching file modules/ssl/mod_ssl.c
Hunk #1 succeeded at 272 (offset 52 lines).
patching file modules/ssl/mod_ssl.h
Hunk #1 succeeded at 63 with fuzz 2 (offset 3 lines).
patching file modules/ssl/ssl_private.h
Hunk #1 succeeded at 149 with fuzz 1 (offset 4 lines).

8. It seems the patch would apply, so overwrite the original patch file 
(scripts/mod_ssl_with_npn.patch in the src folder) with the edited patch file, 
and run the build command again (this will take a while):
$ cp mod_ssl_npn.patch ../scripts/mod_ssl_with_npn.patch
$ cd ..
$ BUILDROOT=mod_ssl ./build_modssl_with_npn.sh
9. Now we have the mod_ssl.so file. (To Gentoo users: to prevent any possible 
conflicts, re-emerge apache:2.4 WITHOUT the ssl USE-flag, but keep the apache 
configs SSL aware). Now we need to add a module load directive to apache, also 
copy the module in place:
# cp mod_ssl.so /usr/lib64/apache2/modules
(the actual apache module directory might differ depending on distro; you might 
also not want to overwrite an existing mod_ssl.so if it's not possible to 
remove it separately or you want a backup, so you can use a different name. But 
you need to use that filename in the apache config then)
In the httpd.conf, there is a section where other modules are loaded, insert a 
line with loading the new mod_ssl module (loading as last module worked for me):
LoadModule ssl_module modules/mod_ssl.so
(Gentoo users: you might want to wrap this around with <IfDefine SSL> 
</IfDefine> tags, if you want to keep the -D SSL functionality from 
conf.d/apache)
10. Restart apache and check if everything works as it used to (https: sites). 
You can check the NPN support with ssllabs.com .

- Now we have an NPN capable apache, we need to build mod_spdy.
0. The build system already has apr, apr-util and some development headers from 
apache 2.2 in the third_party/apache folder. But those are old, we need to 
replace them first.
1. Download a recent apr and apr-util which is known to work with apache 2.4.4. 
The best versions would be those which come with your package manager (the 
sources of those), if you use that for installing apache 2.4 itself.
If you manually compiled apache, use those particular apr and apr-util ( or you 
can download them from http://apr.apache.org/download.cgi ). (Gentoo users: the 
versions gave by portage are fine, use the tar.bz2 files from distfiles)
2. Delete the contents of src/third_party/apache/apr/src, and place the 
contents of the downloaded apr source in place (you should see similar files 
and folders).
3. Do the same with src/third_party/apache/aprutil/src, and apr-util.
4. In the src/third_party/apache/httpd/src folder, there is two other folders: 
include, and os. Delete these, then use the already downloaded (by the 
build_modssl_with_npn.sh script) httpd tar.gz from the mod_ssl folder, and 
extract these two folders here.
5. Now try to compile the module (after a while, it will exit with an error):
$ make BUILDTYPE=Release
[...]
  CXX(target) out/Release/obj.target/spdy_apache/mod_spdy/apache/apache_spdy_stream_task_factory.o
mod_spdy/apache/apache_spdy_stream_task_factory.cc: In constructor 
‘mod_spdy::<unnamed>::ApacheStreamTask::ApacheStreamTask(conn_rec*, 
mod_spdy::SpdyStream*)’:
mod_spdy/apache/apache_spdy_stream_task_factory.cc:101:22: error: ‘struct 
conn_rec’ has no member named ‘remote_addr’
mod_spdy/apache/apache_spdy_stream_task_factory.cc:101:55: error: ‘struct 
conn_rec’ has no member named ‘remote_addr’
mod_spdy/apache/apache_spdy_stream_task_factory.cc:102:22: error: ‘struct 
conn_rec’ has no member named ‘remote_ip’
mod_spdy/apache/apache_spdy_stream_task_factory.cc:102:53: error: ‘struct 
conn_rec’ has no member named ‘remote_ip’
make: *** 
[out/Release/obj.target/spdy_apache/mod_spdy/apache/apache_spdy_stream_task_fact
ory.o] Error 1

6. The problem is the API difference between 2.2 and 2.4. There is a 
description here: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
remote_* fields are now split into client_* and useragent_*. To understand the 
difference, consult the docs above. We will use client_*.
So edit mod_spdy/apache/apache_spdy_stream_task_factory.cc, line 101, and 
replace remote_ip to client_ip (two times), and also replace remote_addr to 
client_addr (two times). Try building again (it will continue where it aborted 
last time)
$ make BUILDTYPE=Release
[...]
  CXX(target) out/Release/obj.target/spdy_apache/mod_spdy/apache/log_message_handler.o
mod_spdy/apache/log_message_handler.cc: In function 
‘void<unnamed>::LogWithHandler(<unnamed>::LogHandler*, int, const 
std::string&)’:
mod_spdy/apache/log_message_handler.cc:75:19: error: ‘aplog_module_index’ 
was not declared in this scope
mod_spdy/apache/log_message_handler.cc: In member function ‘virtual 
void<unnamed>::ServerLogHandler::Log(int, const std::string&)’:
mod_spdy/apache/log_message_handler.cc:93:18: error: ‘aplog_module_index’ 
was not declared in this scope
mod_spdy/apache/log_message_handler.cc: In member function ‘virtual 
void<unnamed>::ConnectionLogHandler::Log(int, const std::string&)’:
mod_spdy/apache/log_message_handler.cc:106:19: error: ‘aplog_module_index’ 
was not declared in this scope
mod_spdy/apache/log_message_handler.cc: In member function ‘virtual 
void<unnamed>::StreamLogHandler::Log(int, const std::string&)’:
mod_spdy/apache/log_message_handler.cc:120:19: error: ‘aplog_module_index’ 
was not declared in this scope
make: *** 
[out/Release/obj.target/spdy_apache/mod_spdy/apache/log_message_handler.o] 
Error 1

7. This problem is caused by the change in logging, as described here: 
http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html#upgrading_logging
Edit the mod_spdy/apache/log_message_handler.cc file, in the 24th line, we see 
the inclusion of http_log.h . After that, insert the following line:
APLOG_USE_MODULE(spdy);
Then continue compiling.
$ make BUILDTYPE=Release
[...]
  CXX(target) out/Release/obj.target/mod_spdy/mod_spdy/mod_spdy.o
mod_spdy/mod_spdy.cc: In function ‘void<unnamed>::ChildInit(apr_pool_t*, 
server_rec*)’:
mod_spdy/mod_spdy.cc:257:17: error: ‘struct server_rec’ has no member named 
‘loglevel’
mod_spdy/mod_spdy.cc:258:38: error: ‘struct server_rec’ has no member named 
‘loglevel’
make: *** [out/Release/obj.target/mod_spdy/mod_spdy/mod_spdy.o] Error 1

8. Unfortunately this change is not described in the documentation above, but 
searching for the reference of the server_rec gives this link: 
http://ci.apache.org/projects/httpd/trunk/doxygen/structserver__rec.html
Indeed, there is no loglevel field there, but there is an other field, "log", 
with type "ap_logconf". Following the type link, it has a field named "level" 
with type int. So this becomes log.level instead of loglevel.
So edit mod_spdy/mod_spdy.cc, go to line 257, and change loglevel to log.level 
(two times). Continue compiling.
$ make BUILDTYPE=Release
[...]

9. This time the module compiles. Move and load the module the same way as 
mod_ssl. You also need to add a "SpdyEnabled on" directive after loading the 
mod_spdy module. Restart apache, and test it with Chrome and ssllabs.com as 
described in the original install guide.

Original comment by cf0...@gmail.com on 18 Apr 2013 at 6:48

Attachments:

• 2.2_to_2.4.diff

[GoogleCodeExporter]

Clarification to my previous post:

If you apply the patch, you still need to replace the third_party folder 
content described in the mod_spdy compilation section, 0-4, before issuing make.

Original comment by cf0...@gmail.com on 18 Apr 2013 at 6:59

[GoogleCodeExporter]

IS there a binary for this fix yet for yum install?

Original comment by joseff...@gmail.com on 19 Apr 2013 at 5:19

[GoogleCodeExporter]

I don't have a suse at hand, but it shouldn't be that hard to create such a 
package.

Original comment by cf0...@gmail.com on 19 Apr 2013 at 9:42

[GoogleCodeExporter]

I have managed to build mod_spdy for apache 2.4 as well, but the problem was 
that it would coredump when running with the event worker model - can you check 
whether your method works when run this way?

Original comment by g...@magisto.com on 25 Apr 2013 at 1:48

[GoogleCodeExporter]

Well, I use the worker MPM. If you read the event MPM documentation ( 
http://httpd.apache.org/docs/2.4/mod/event.html ), it says: "The improved 
connection handling does not yet work for certain connection filters, in 
particular SSL. For SSL connections, this MPM will fall back to the behaviour 
of the worker MPM and reserve one worker thread per connection". As SPDY makes 
sense only with SSL, I don't see the point of using the event MPM instead of 
worker. It shouldn't crash the server, that's true. But if you want to 
experiment with SPDY, don't use the event one.

Original comment by cf0...@gmail.com on 2 May 2013 at 1:09

[GoogleCodeExporter]

official alpha/beta release could be useful. Thank for your work!

Original comment by d.ok...@gmail.com on 8 May 2013 at 11:57

[GoogleCodeExporter]

I'd like to ask, if some developer is interested in this topic? If yes, I'm 
ready try help with code and testing.

Original comment by d.ok...@gmail.com on 27 Jun 2013 at 8:46

[GoogleCodeExporter]

Is an alpha/beta version planned for this? 
Thanks for your help

Original comment by JungleBo...@gmail.com on 6 Aug 2013 at 7:49

[GoogleCodeExporter]

I would like to move whatever constructs are needed by mod_spdy into Apache 
httpd's trunk. My goal is to move a lot of the hacks into a new MPM...

FWIW, I'm also jim@apache.org :)

Original comment by jim...@gmail.com on 17 Sep 2013 at 7:25

[GoogleCodeExporter]

What is actual status? Does anyone work on SPDY 3.1 SPEC for Apache 2.4?

Original comment by d.ok...@gmail.com on 21 Oct 2013 at 11:09

[GoogleCodeExporter]

Any feedback from Project Members on an ETA for this?

Original comment by edward.a...@gmail.com on 11 Nov 2013 at 11:36

[GoogleCodeExporter]

seems that this module is discontinued?

Original comment by therealc...@gmail.com on 4 Feb 2014 at 12:52

[GoogleCodeExporter]

Meanwhile we switched to nginx (with SPDY 2) and they'll get SPDY 3 soon.

Original comment by d.ok...@gmail.com on 4 Feb 2014 at 12:55

[GoogleCodeExporter]

I'm not sure what is going on, but I emailed Jim@apache.org and got no response 
either.  I'm assuming they just gave up.

It's a shame too, because spdy has such potential, but without it working with 
Apache many of us can't adopt it.

Original comment by bgibson...@gmail.com on 26 Feb 2014 at 7:44

[GoogleCodeExporter]

"It's a shame too, because spdy has such potential, but without it working with 
Apache many of us can't adopt it."

Agreed. All the sites I'm involved with or can influence run Apache. I've 
gotten management buy-in that SPDY is a worthwhile use of our resources, but 
we're unable to implement it without a way to do so for Apache 2.4. 

Original comment by cque...@gmail.com on 26 Feb 2014 at 7:54

[GoogleCodeExporter]

For those interested I forked the repo to github and have a working code base 
for openssl 1.0.1f and apache 2.4.7 (Running at https://blck.io)

https://github.com/eousphoros/mod-spdy

Original comment by buckle...@gmail.com on 26 Feb 2014 at 10:00

[GoogleCodeExporter]

"Cannot load /usr/lib/httpd/modules/mod_spdy.so into server: 
/usr/lib/httpd/modules/mod_spdy.so: undefined symbol: ap_log_cerror"

Any news for 2.4 comp. ?

Original comment by seyhunca...@gmail.com on 29 Mar 2014 at 8:49

[GoogleCodeExporter]

any news on this?

Original comment by rene.noo...@gmail.com on 16 Apr 2014 at 6:59

[GoogleCodeExporter]

Nope, I think they gave up on 2.4 for some reason.  Haven't seen any updates 
for a long time.  Never got a reply from jim over at apache either.

Original comment by bgibson...@gmail.com on 16 Apr 2014 at 11:33

[GoogleCodeExporter]

It came up on the apache-dev mailing list in February and March. I looks to me 
like nobody it actually working on it, just brainstorming.

http://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3C474C1241-99C0-
4D21-A095-B6A752CDEC6A@jaguNET.com%3E
http://mail-archives.apache.org/mod_mbox/httpd-dev/201403.mbox/%3C37FB1CDE-324B-
49BA-9602-01CC98A5B663@jaguNET.com%3E

Original comment by Greg.Mar...@gmail.com on 16 Apr 2014 at 3:44

[GoogleCodeExporter]

I forgot to mention, that i have patch, it's based on earlier comments from 
this issue, and it's at least compiling, didn't really test more

you can find the apache2.4.patch from here:
http://git.pld-linux.org/?p=packages/apache-mod_spdy.git;a=tree

you may need some other adjustments as well from there, therefore i linked to 
repo, not individual patch

Original comment by elan.ruu...@gmail.com on 16 Apr 2014 at 4:06

[GoogleCodeExporter]

looking forward to this release. its a little disappointing its still not out 
considering google is pushing https everywhere so hard.

Original comment by georgemi...@gmail.com on 10 Dec 2014 at 11:24

[GoogleCodeExporter]

george: you can take my patch from note 26

it compiles, but i haven't really runtime tested it. so would be nice to get 
feedback on that patch. it will encourage mod-spdy maintainer to take if more 
people confirm it's cool.

Original comment by elan.ruu...@gmail.com on 11 Dec 2014 at 11:22

[GoogleCodeExporter]

According to 
http://googledevelopers.blogspot.com/2014/06/modspdy-is-now-apache-project.html 
they have donated the code to the Apache Software Foundation, and this 
repository is now in maintenance only.

Original comment by www.will...@gmail.com on 12 Dec 2014 at 2:44

[GoogleCodeExporter]

Elan thank you for your kind reply and your work to help the community. I would 
love to. Unfortunately I am in a PROD environment with no DEV area set up yet :(

Original comment by georgemi...@gmail.com on 12 Dec 2014 at 6:26

[GoogleCodeExporter]

My understanding is that SPDY is a research project that now days is not under 
active development. It is replaced by HTTP/2 which is expected to be released 
in February 2015. All bigger browsers already support the current HTTP/2 draft.
The question is more when Apache will serve it's content over HTTP/2 protocol 
but this ticket/issue is not about HTTP/2. I think this ticket/issue should be 
marked as "Won't fix". SPDY was of interest when this ticket/issue was created 
but not anymore in my opinion.

Original comment by goo...@post.blinkiz.com on 12 Dec 2014 at 8:09

[GoogleCodeExporter]

For now, just use nginx for SPDY 3 and await HTTP/2.

Original comment by aj.sla...@gmail.com on 12 Dec 2014 at 10:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

indeed. seems asf repo has code loaded, and patches for 2.4

https://svn.apache.org/repos/asf/httpd/mod_spdy/trunk/

however, it's loaded with no previous svn history from this repo, not even 
reference what was the checkpoint where it was transfer :(

$ svn log https://svn.apache.org/repos/asf/httpd/mod_spdy/ | less

$ svn log -c 1591620 https://svn.apache.org/repos/asf/httpd/mod_spdy/
------------------------------------------------------------------------
r1591620 | jim | 2014-05-01 14:39:27 +0300 (Thu, 01 May 2014) | 2 lines

Initial load : mod_spdy code donation from Google

$ svn log -c 1591622 https://svn.apache.org/repos/asf/httpd/mod_spdy/
------------------------------------------------------------------------
r1591622 | jim | 2014-05-01 14:43:36 +0300 (Thu, 01 May 2014) | 2 lines

Initial load : mod_spdy for 2.4.x/trunk... in devel

and even no info where this code originated from:

$ svn log -c 1619560 https://svn.apache.org/repos/asf/httpd/mod_spdy/
------------------------------------------------------------------------
r1619560 | jim | 2014-08-21 22:59:58 +0300 (Thu, 21 Aug 2014) | 2 lines

Sync w/ 2.4.10...

$ svn diff -c 1619560 https://svn.apache.org/repos/asf/httpd/mod_spdy/|less 
------------------------------------------------------------------------
r1619560 | jim | 2014-08-21 22:59:58 +0300 (Thu, 21 Aug 2014) | 2 lines

Sync w/ 2.4.10...

Original comment by elan.ruu...@gmail.com on 13 Dec 2014 at 5:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

and the asf repo contains build files that shouldn't even loaded to vcs!

https://svn.apache.org/repos/asf/httpd/mod_spdy/trunk/build/

.... zero knowledge transfer!

Original comment by elan.ruu...@gmail.com on 13 Dec 2014 at 6:13

[GoogleCodeExporter]

https://svn.apache.org/repos/asf/httpd/mod_spdy/trunk/mod_spdy/common/VERSION 

seems version there is 0.9.4.1, but here it's already 0.9.4.3
https://code.google.com/p/mod-spdy/source/browse/tags/0.9.4.3/src/mod_spdy/commo
n/VERSION

so, don't even know which code to trust. asf version is total crap, here's 
newer, but here's no apache 2.4 support...

Original comment by elan.ruu...@gmail.com on 13 Dec 2014 at 6:17