Originally created by @sword-jin on GitHub (Nov 28, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4563 ### Describe the feature request Like the title, we can enable `h2c` support in vhost server, there is a PR already https://github.com/fatedier/frp/pull/4561 ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:19:04 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:19:07 -06:00

Author

Owner

@sword-jin commented on GitHub (Nov 28, 2024):

@fatedier I think it's safe to wrapper the handler with h2c if we don't want to introduce new optional parameter

@sword-jin commented on GitHub (Nov 28, 2024): @fatedier I think it's safe to wrapper the `handler` with `h2c` if we don't want to introduce new optional parameter

gitea-mirror commented

2026-05-05 14:19:08 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 28, 2024):

Could you provide relevant documentation or examples from other projects? Also, please add an end-to-end (e2e) test case to ensure existing functionality is not affected.

@fatedier commented on GitHub (Nov 28, 2024): Could you provide relevant documentation or examples from other projects? Also, please add an end-to-end (e2e) test case to ensure existing functionality is not affected.

gitea-mirror commented

2026-05-05 14:19:08 -06:00

Author

Owner

@sword-jin commented on GitHub (Nov 28, 2024):

I see, I will write a e2e test case, I think we can see the real user case in the e2e case

@sword-jin commented on GitHub (Nov 28, 2024): I see, I will write a e2e test case, I think we can see the real user case in the e2e case

gitea-mirror commented

2026-05-05 14:19:08 -06:00

Author

Owner

@sword-jin commented on GitHub (Nov 29, 2024):

I can't reprocude the bug when running all the components locally, this is my playground be0c28f7a1/cmd/client/main.go (L46)

sequenceDiagram
    autonumber
    actor B as Browser
    box Purple On Cloud
    participant C as Caddy
    participant FS as Frps
    end
    box Grey On Local
    participant FC as Frpc
    participant LS as LocalServer
    end
    
    B ->> C: request 443
    C ->> C: tls termination
    C ->> FS: reverse proxy to 8888
    FS ->>+ FC: notify the client new connection
    FC ->>- FS: new tcp connection
    FS ->> FC: forward request
    FC ->> LocalServer: forward request

This diagram Illuminates how a request reach out the local server. This repo trys to build the same worfklow, but fortunately it doesn't work.

In the playground, we use a mock certificate, and the client skip the validation

When the frps and caddy on real cloud with a real tls certificate, the client always gets stream error: internal: protocol error: no Grpc-Status trailer: unexpected EOF at be0c28f7a1/cmd/client/main.go (L46-L48)

Form the logs of caddy and frps and local server, the request has been handled successfully, the problem is the trailer header is missing.

What I did to fix is add a h2c layer in frp vhost server and use http2 transport

I check the frps's response, left is without h2c, right is with h2c, the difference is left doesn't have Trailer:Grpc-Status which cause the error

@sword-jin commented on GitHub (Nov 29, 2024): I can't reprocude the bug when running all the components locally, this is my playground https://github.com/sword-jin/caddy-frp-grpc-streaming/blob/be0c28f7a1a0972a6103b8434d43f73ea51f9939/cmd/client/main.go#L46 ```mermaid sequenceDiagram autonumber actor B as Browser box Purple On Cloud participant C as Caddy participant FS as Frps end box Grey On Local participant FC as Frpc participant LS as LocalServer end B ->> C: request 443 C ->> C: tls termination C ->> FS: reverse proxy to 8888 FS ->>+ FC: notify the client new connection FC ->>- FS: new tcp connection FS ->> FC: forward request FC ->> LocalServer: forward request ``` This diagram Illuminates how a request reach out the local server. This repo trys to build the same worfklow, but fortunately it doesn't work. **In the playground**, we use a mock certificate, and the client skip the validation When the frps and caddy on real cloud with a real tls certificate, the client always gets `stream error: internal: protocol error: no Grpc-Status trailer: unexpected EOF` at https://github.com/sword-jin/caddy-frp-grpc-streaming/blob/be0c28f7a1a0972a6103b8434d43f73ea51f9939/cmd/client/main.go#L46-L48 Form the logs of caddy and frps and local server, the request has been handled successfully, the problem is the trailer header is missing. What I did to fix is add a h2c layer in frp vhost server and use `http2 transport` I check the frps's response, left is without h2c, right is with h2c, the difference is left doesn't have `Trailer:Grpc-Status` which cause the error ![image](https://github.com/user-attachments/assets/c0cdb4f7-fbb5-4085-a12c-66271bbce757)

gitea-mirror commented

2026-05-05 14:19:09 -06:00

Author

Owner

@fatedier commented on GitHub (Dec 5, 2024):

@fatedier I think it's safe to wrapper the handler with h2c if we don't want to introduce new optional parameter

Can the code be modified in this way? And verify that it does not affect other requests?

@fatedier commented on GitHub (Dec 5, 2024): > @fatedier I think it's safe to wrapper the `handler` with `h2c` if we don't want to introduce new optional parameter Can the code be modified in this way? And verify that it does not affect other requests?

gitea-mirror commented

2026-05-05 14:19:09 -06:00

Author

Owner

@sword-jin commented on GitHub (Dec 13, 2024):

"golang.org/x/net/http2/h2c" is completely compatible to the existing http1.1, we can verify it doesn't affect all the current behavior(by current e2e test

but for http2.transparent, we need another option flag

@sword-jin commented on GitHub (Dec 13, 2024): `"golang.org/x/net/http2/h2c"` is completely compatible to the existing http1.1, we can verify it doesn't affect all the current behavior(by current e2e test but for http2.transparent, we need another option flag

gitea-mirror commented

2026-05-05 14:19:10 -06:00

Author

Owner

@fatedier commented on GitHub (Dec 13, 2024):

A quick look shows that server-side support for h2c seems compatible and can be directly added. However, proxying to the backend using http2.Transport is incompatible. Perhaps we could split the work and submit the former first.

For proxying to the backend, there are two main approaches to consider:

Achieving compatibility with both, possibly through an upgrade mechanism or a fallback mechanism.
Allowing the backend service to configure its own interaction protocol.
I prefer the second approach, but the current code has limited support in this regard. There has always been a plan for future refactoring to provide more fine-grained configuration support.

@fatedier commented on GitHub (Dec 13, 2024): A quick look shows that server-side support for h2c seems compatible and can be directly added. However, proxying to the backend using http2.Transport is incompatible. Perhaps we could split the work and submit the former first. For proxying to the backend, there are two main approaches to consider: Achieving compatibility with both, possibly through an upgrade mechanism or a fallback mechanism. Allowing the backend service to configure its own interaction protocol. I prefer the second approach, but the current code has limited support in this regard. There has always been a plan for future refactoring to provide more fine-grained configuration support.

gitea-mirror commented

2026-05-05 14:19:10 -06:00

Author

Owner

@sword-jin commented on GitHub (Dec 13, 2024):

I agree, https://github.com/fatedier/frp/pull/4582 adding h2c wapper is compatible, for http2.Transport, I'd like to take a deep look or you can support the second approach if you are free.

@sword-jin commented on GitHub (Dec 13, 2024): I agree, https://github.com/fatedier/frp/pull/4582 adding h2c wapper is compatible, for http2.Transport, I'd like to take a deep look or you can support the second approach if you are free.

gitea-mirror commented

2026-05-05 14:19:11 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 28, 2024):

Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Dec 28, 2024): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.