H2 resurrection

[w0l4i]

Why not H2 until Gas then goes http 1.1 to origin ?

H2 performance maintain + H1 reliability For Full mode

Client H2 > Gas - (H2 to Http1 transform) > Http 1.1 With encryption over ssl to vps > Nginx / caddy (ssl termination + reverse proxy) to node tunnel

[w0l4i]

@dazzling-no-more

[dazzling-no-more]

Appreciate the thought, but a few things don't quite line up with how mhrv-rs is actually built:

1. Client → Gas is already H2. domain_fronter.rs advertises ALPN ["h2", "http/1.1"] on the fronted TLS connection to Google's edge and uses H2 whenever the edge agrees. You're not adding H2 here, it's the current state.

2. Apps Script isn't a protocol bridge. doPost(e) receives a single fully-buffered POST body — there's no H2 stream entering the script to "transform". Outbound is UrlFetchApp.fetch(...), a Google SDK call: you don't pick H1 vs H2, you don't get streaming, you don't get multiplexing. It's request/response with a 50 MB cap.

3. The Full-mode floor is structural, not protocol. ~2 s per Apps Script round-trip, 30 concurrent per account, 6-min execution cap. No HTTP version on the Gas→VPS hop moves those numbers. The pipelined batch multiplexer already gives you multiplexing-equivalent behavior at a higher layer.

4. Nginx/Caddy in front of tunnel-node already works — it's in tunnel-node/README.md. Orthogonal to H1/H2.

5. For Iran specifically: DPI is only on Client → Google-IP. Gas → VPS isn't on a censored path, so optimizing wire format there isn't the lever.

So the "H2 edge, H1 origin" pattern you're describing is correct in general (it's how CDN→origin works), and mhrv-rs already does it where it's controllable. The piece you'd want to add isn't expressible in Apps Script.