Supporting http/2 with server push #626

New Issue

GiteaMirror · 2025-11-02T03:30:47-06:00

GiteaMirror commented

2025-11-02 03:30:47 -06:00

Originally created by @tony199555 on GitHub (Apr 8, 2017).

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 .

Originally created by @tony199555 on GitHub (Apr 8, 2017). 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](https://github.com/rsc/letsencrypt) .

GiteaMirror added the type/feature issue/stale labels 2025-11-02 03:30:47 -06:00

GiteaMirror closed this issue

2025-11-02 03:30:47 -06:00

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@strk commented on GitHub (Apr 8, 2017):

See #1167 for Let's Encrypt integration

@strk commented on GitHub (Apr 8, 2017): See #1167 for Let's Encrypt integration

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@tboerger commented on GitHub (Apr 8, 2017):

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.

@tboerger commented on GitHub (Apr 8, 2017): 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.

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@lunny commented on GitHub (Apr 8, 2017):

So that could be a build tag

@lunny commented on GitHub (Apr 8, 2017): So that could be a build tag

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@tboerger commented on GitHub (Apr 8, 2017):

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

@tboerger commented on GitHub (Apr 8, 2017): Not any build tag at all, http2 is part of the stdlib. It's just working with https connections only

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@tony199555 commented on GitHub (Apr 9, 2017):

@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

@tony199555 commented on GitHub (Apr 9, 2017): @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](https://blog.golang.org/7years)

GiteaMirror commented

2025-11-02 03:30:48 -06:00

@tboerger commented on GitHub (Apr 9, 2017):

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

@tboerger commented on GitHub (Apr 9, 2017): I know, but it's up to the user to configure https.

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@alexandrestein commented on GitHub (Jan 25, 2018):

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?

@alexandrestein commented on GitHub (Jan 25, 2018): 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?

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@thehowl commented on GitHub (Jan 30, 2018):

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

@thehowl commented on GitHub (Jan 30, 2018): Are you proxying through nginx or are you connecting to Gitea directly?

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@alexandrestein commented on GitHub (Jan 31, 2018):

Directly.

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

@alexandrestein commented on GitHub (Jan 31, 2018): Directly. Does it can be related to my configuration file? I'm using `GZIP` for example.

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@juppin commented on GitHub (Feb 7, 2018):

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.

@juppin commented on GitHub (Feb 7, 2018): 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.

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@bkcsoft commented on GitHub (Feb 10, 2018):

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

@bkcsoft commented on GitHub (Feb 10, 2018): @juppin No browser allows for unencrypted HTTP2 though. So even if the spec allows it, it's essentally useless for browser usage

GiteaMirror commented

2025-11-02 03:30:49 -06:00

@tony199555 commented on GitHub (Feb 10, 2018):

@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.

@tony199555 commented on GitHub (Feb 10, 2018): @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.

GiteaMirror commented

2025-11-02 03:30:50 -06:00

@juppin commented on GitHub (Feb 10, 2018):

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.

@juppin commented on GitHub (Feb 10, 2018): 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.

GiteaMirror commented

2025-11-02 03:30:50 -06:00

@alexandrestein commented on GitHub (Feb 12, 2018):

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".

@alexandrestein commented on GitHub (Feb 12, 2018): `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".

GiteaMirror commented

2025-11-02 03:30:50 -06:00

@tankerkiller125 commented on GitHub (Aug 3, 2018):

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

@tankerkiller125 commented on GitHub (Aug 3, 2018): 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

GiteaMirror commented

2025-11-02 03:30:51 -06:00

@Deuchnord commented on GitHub (Jan 8, 2019):

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.

@Deuchnord commented on GitHub (Jan 8, 2019): Hey there, just fall onto this old issue… You may be interested in this new protocol called [Mercure](/dunglas/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. :slightly_smiling_face: Plus, there is [a draft RFC](https://datatracker.ietf.org/doc/draft-dunglas-mercure/) for the protocol.

GiteaMirror commented

2025-11-02 03:30:51 -06:00

@stale[bot] commented on GitHub (Mar 9, 2019):

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[bot] commented on GitHub (Mar 9, 2019): 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.

GiteaMirror commented

2025-11-02 03:30:51 -06:00

@stale[bot] commented on GitHub (Mar 23, 2019):

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

@stale[bot] commented on GitHub (Mar 23, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 11:47:55 -06:00

[PR #626] [MERGED] Bug fix release #15497

Sign in to join this conversation.