caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
58.01k stars 4.03k forks source link

WebTransport support via quic-go #5421

Closed MonkeyBrothers closed 1 year ago

MonkeyBrothers commented 1 year ago

hello,I have been using webtransport(base quic-go) recently to transfer some data. I want to use caddy as my proxy forwarding, but I tried the following configuration is not feasible.

Caddyfile:

{
      debug
}
webtransport.xxx.com {
      tls 2507511047@qq.com
      reverse_proxy 10.176.237.64:9001 
}

docker-compse.yml:

version: "3.9"
services:
  caddy:
    image: caddy
    restart: unless-stopped
    network_mode: "host"
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./data:/data
      - ./config:/config
      - ./Caddyfile:/etc/caddy/Caddyfile
    logging:
      driver: "json-file"
      options:
        max-size: "500m"
        max-file: "3"

Access error:

Failed to establish a connection to https://webtransport.xxx.com: net::ERR_METHOD_NOT_SUPPORTED

need help

How should I configure to support the forward quic protocol?

francislavoie commented 1 year ago

What do you see in Caddy's logs when you try to connect?

I don't know much about WebTransport so I'm not sure I'll be much help.

francislavoie commented 1 year ago

@marten-seemann do you have any insight on if we're missing anything to allow this to work?

MonkeyBrothers commented 1 year ago

@francislavoie

When I accessed it, I could see the following log.

image

I was able to transfer data locally when using the webtransport mode. It is also possible to transfer data without using the caddy agent on the server.

marten-seemann commented 1 year ago

How does the setup look like? You're running Caddy on the reserve proxy, and webtransport-go on both endpoints? I assume that proxying the Extended CONNECT request is not a problem, since that's just a normal HTTP request (with some not so normal header fields).

But how would streams opened on the WebTransport session make it through the reverse proxy?

MonkeyBrothers commented 1 year ago

webtransport-go(port:9001) and caddy(port:443) are on a machine. I want to forward traffic to my webtransport-go through caddy's port 443.

I use HTML5 to connect my server.

webtransport-go(port:9001) and caddy(port:443) are on a machine. I want to forward traffic to my webtransport-go through caddy's port 443.

I use HTML5 to connect my server.

const url = 'https://webtransport.xueche.com/test';
transport = new WebTransport(url);
transport.closed.then(() => {
    console.log(`The HTTP/3 connection to ${url} closed gracefully.`);
}).catch((error) => {
    console.error('The HTTP/3 connection to ${url} closed due to ${error}.');
});
await transport.ready;
marten-seemann commented 1 year ago

That can't work. As long as Caddy isn't aware of WebTransport, it won't be able to make sense of WebTransport streams.

francislavoie commented 1 year ago

@marten-seemann so I guess this isn't possible until https://github.com/caddyserver/caddy/issues/5086 is done?

MonkeyBrothers commented 1 year ago

That can't work. As long as Caddy isn't aware of WebTransport, it won't be able to make sense of WebTransport streams.

I can understand that it doesn't support webtransport-go, but does it support h3? I seem to be able to access it when I use h3.

marten-seemann commented 1 year ago

@marten-seemann so I guess this isn't possible until #5086 is done?

That would be a prerequisite. If proxying HTTP/3 doesn't even work, the Extended CONNECT request won't even make it through.

I don't think that's all though. If you want to proxy WebTransport, your proxy needs to be WebTransport-aware.

francislavoie commented 1 year ago

Okay, thanks. I'll close this issue for now in favour of that one, and WebTransport support can be looked into later on with that in mind.

francislavoie commented 1 year ago

Although what might work is https://github.com/mholt/caddy-l4 which could terminate TLS and then proxy UDP, I think. But I'm not sure if the TLS handler in caddy-l4 supports TLS over UDP.

MonkeyBrothers commented 1 year ago

Although what might work is https://github.com/mholt/caddy-l4 which could terminate TLS and then proxy UDP, I think. But I'm not sure if the TLS handler in caddy-l4 supports TLS over UDP.

Thank you very much. I'll try

marten-seemann commented 1 year ago

Although what might work is https://github.com/mholt/caddy-l4 which could terminate TLS and then proxy UDP, I think. But I'm not sure if the TLS handler in caddy-l4 supports TLS over UDP.

This would probably be the best solution: https://datatracker.ietf.org/doc/html/rfc9298

@marten-seemann so I guess this isn't possible until #5086 is done?

quic-go should have everything you need to resolve that issue, doesn’t it?

francislavoie commented 1 year ago

quic-go should have everything you need to resolve that issue, doesn’t it?

I think it does, but it's just not a priority of mine to work on that feature. I don't particularly need H3 for anything myself.

JeDaYoshi commented 3 months ago

5086 was closed with experimental HTTP/3 support implemented for reverse proxies, any chance this issue can be reopened to keep in mind? Would love to see WebTransport support on Caddy.

francislavoie commented 3 months ago

We don't have any plans to work on it. If someone wants to contribute the feature, then by all means. I don't think we need an issue open for that.

marten-seemann commented 2 months ago

Note that development of webtransport-go is currently on hold due to a lack of funding (https://github.com/quic-go/webtransport-go/pull/156), and WebTransport support is going to break as soon as browsers update to a new IETF draft version.

Please feel free to reach out to me if your company / project relies on WebTransport.