Supporting http/2 with server push

[tony199555]

Go 1.8 comes with a eagerly anticipated feature: Http/2. One feature of http/2 is server push, which in theory increase the performance of web page delivery.
So I am wondering if by any chance gitea 1.3 will be able to move to go 1.8.

P.S. Since http/2 requires a SSL certificate, do you see that we could also include Let's Encrypt with gitea. I have seen a couple solutions that works with go, i.e. this one from rsc .

[strk]

See #1167 for Let's Encrypt integration

[tboerger]

We can build the prebuilt binaries with 1.8, but we won't drop support for older go versions as even developers like @strk are still working on 1.6. For the docker image we are using the go version that is available on alpine edge.

[lunny]

So that could be a build tag

[tboerger]

Not any build tag at all, http2 is part of the stdlib. It's just working with https connections only

[tony199555]

@tboerger After reading more about different version (1.6 - 1.8), I found out that 1.6 actually supports http/2, but not server push, which it is new for 1.8. I guess we could still use http/2 with 1.6 but not server push. Then it should have increase performance AND security by just using http/2 per se.

Reference:
Seven years of Go

[tboerger]

I know, but it's up to the user to configure https.

[alexandrestein]

When TLS is enable the communication is still http/1.1 in my Chromium debugger.
I'm using the Docker image which come with Go1.9.2.

It should use HTTP2 by itself because of the go http package, right?

[thehowl]

Are you proxying through nginx or are you connecting to Gitea directly?

[alexandrestein]

Directly.

Does it can be related to my configuration file? I'm using GZIP for example.

[juppin]

HTTP2 is also defined for unencrypted transport... It's called h2c.
I dont know why golang wont implement this in there std lib.

https://github.com/hkwi/h2c
Clould h2c implemented in gitea with the above library?
That would be great :-)

I want to use apache with proxy_http2 as reverse proxy without encryption between gitea and apache.
For me i cloud not use gitea directly, because i use port 80 and 443 for other sites to on my ip too.

[bkcsoft]

@juppin No browser allows for unencrypted HTTP2 though. So even if the spec allows it, it's essentally useless for browser usage

[tony199555]

@juppin Well, given the fact that Chrome will begin to block non-https website by showing what insecure https website shows now; and it is now displaying "insecure" on the address bar for the http website, the trend is going to be https for every website. So it does not hurt to use the ssl for proxy, too.

[juppin]

But using h2c from gitea to reverse proxy is a very useful usecase...

I do not want to use unecrypted http2 over my public ip.
All my virtual hosts on apache with http on port 80 do only redirect to https.

[alexandrestein]

HTTP2 main goal is to optimize the network and reduce the latency while keeping the compatibility with HTTP/1.x.

If you are proxing to a local network or to the localhost I don't think you will see any significant performance gain.

For me, it's definitely not a "useful usecase".

[tankerkiller125]

Just adding an autmatic Link header would help out even in HTTP1.1 as those of us who do Cache and Pushing through a web server (Caddy for example) can configure them to push assets that are in the Link header, not only that but people who use Cloudflare would also get that extra benefit because Cloudflare also pays attention to the Link header

[Deuchnord]

Hey there, just fall onto this old issue…
You may be interested in this new protocol called Mercure, created by @dunglas. It seems very simple to implement on server-side and is powered by HTTP/2 and server push. It is written in Go and has a built-in library for this language. 🙂
Plus, there is a draft RFC for the protocol.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.