- HTTP/2 only works in Apache if you enable the module, switch it on manually, and declare in the Apache configs that you want to accept it. It is not shipped by default.

- When you switch HTTP/2 on, if you are running PHP on a Debianesque (Other?) platform, the HTTP/2 module will sulk and refuse to function until you switch off the `mpm_prefork` module, because thread safety

- `mpm_prefork` is default on SO MANY DEBIAN THINGS even though there are so many blogposts that describe it as crusty and evil

- Sorting this out is a pain; see previous post, there is a helpful link; the `php_fpm` module works okay (better?) but it means I can't do an apples-to-apples comparison

- You will also need to enable the `headers` and `setenvif` modules, of not already

- Placement of the header-generation in the Apache config file is *critical*; there are simple some places where you can put `Header` directives and they will be ignored/dropped

- I am conditionally enabling the header for occasions where another (EOTK-related) header is not present; you probably don't need to do this but it might be useful for debugging or something, so I will present the whole thing; this works for me:

- you can see the failed http/1.1 experiment in the above 

- In my previous email, I cited a fragment of Tor config which I was using (0.3.4.8) to create a v3 Onion; I have stopped using v3 onions for the testing, for the moment.

- I am not sure if it's something that I did wrong with that V3 config (perhaps `HiddenServiceNumIntroductionPoints 3`? or because the same 0.3.4.8 daemon is also serving the v2 onion address for EOTK?) but I was finding that connections from my desktop machine to the v3 Alt-Svc onion were very, very flaky; TorBrowser refused to connect to it, could not resolve it in the HSDir, restarting TorBrowser did not help, using `nc` via TorBrowser SOCKS would return `Error 4` even though the same onion service daemon (running for EOTK) was solidly up.

- as soon as I dropped down to a v2 onion for Alt-Svc, testing became a lot more stable. I am sure it'll get better in time, but for the moment I am sticking to v2.

No wonder people are having problems getting this working: between non-default software on the backend, attempting to use a cutting-edge v3 onion in the middle, and freshly-released client software which doesn't provide any "success" status/debug information whatsoever, of *course* it's gonna be tricky.  I have 30 years of daily experience and it took me several hours to work out what the hell was going on. 

This is NOT anyone's fault - there is no blame here, and matters will doubtless improve - but I am writing this as a reference to quell the complaints from <people> that <zomg this is hard>.

Of course it's hard: you're standing on the bleeding edge.

    -a