Allow Direct Proxying

[jalcine]

So i have a use case for trillium-proxy where I'd want to proxy requests from one path to another one (like the proxy does) but without replacing the path. For example, I'd like to receive requests at /_proxy_/service and send it to http://remote.service/location. The /location part is important.

[jalcine]

I have a PR to add this optional functionality https://github.com/trillium-rs/trillium/compare/main...jalcine:allow-proxy-to-use-native-url?expand=1 but I'm running into a HTTP version mismatch:

[2022-03-16T02:53:01Z ERROR trillium_client::conn] Version
[2022-03-16T02:53:01Z ERROR trillium_client::conn] partial head content: text/html
    Content-Length: 233
    Connection: keep-alive
    Server: gunicorn/19.9.0
    Access-Control-Allow-Origin: *
    Access-Control-Allow-Credentials: true


[2022-03-16T02:53:01Z ERROR trillium_proxy] proxy/src/lib.rs:218 conn_try error: invalid HTTP version

[jbr]

Could you provide examples of how you'd want the url rewritten? I was planning on adding some sort of general rewriting functionality, would be useful to have a use case to build towards.

I'm not sure what's up with the http error, but I think we probably want a solution that accepts an optional Fn(Url) -> Url rewriting function to support arbitrary url transformations

[jalcine]

I like that approach. I was hoping for no transforming to occur - that the path from the current conn be completely ignored but the querystring and/or request body be utilized - working a bit like the proxy_pass directive from nginx .

[jbr]

I'm confused about the proxy_pass comparison because although proxy_pass changes the url base, it retains the path and querystring. I think see what you're looking for, though. Would this interface suit your needs? Do you also need to change other things about the request, like method or headers?

        Proxy::new({
            let url = Url::parse("http://remote.service/location").unwrap();
            move |conn: &Conn| {
                let mut url = url.clone();
                if !conn.querystring().is_empty() {
                    url.set_query(Some(conn.querystring()));
                }
                Some(url)
            }
        }),

[jalcine]

This would be perfect. Preserving the method and headers would be ideal as well.

My specific use case is on the project's tracker; that adds more context in the specific use-case I'm looking for.

[jbr]

Oh, if you really only ever want to receive requests at the specific url, I recommend using Router. trillium_router::router().all("_proxy_/service", Proxy::new("http://remote.service/location")) will send all requests to /_proxy_/service to http://remote.service/location. The fact that querystrings are dropped is a bug, and I'll get a patch up that fixes that immediately. Let me know if this supports your use case and I'll punt on the more complex rewriting case until I have a clear use case (like a proxy_pass that has multiple upstreams and a proxy selection strategy)

[jbr]

This would also work with a *, so trillium_router::router().all("_proxy_/service/*", Proxy::new("http://remote.service/location")) will rewrite /_proxy_/service/hello to http://remote.service/location/hello, etc. Not entirely sure if that's useful for this application

[jalcine]

Ah, I didn't notice that re: query strings, I figured that was some unintentional behavior.

[jalcine]

I can test this out; I'll report back

[jbr]

this works because the router uses Conn::push_path to rewrite the path for the contained handlers.

Note, however, that the way that you're using proxy.run will not support proxying websockets, because that requires further lifecycle hooks (it treats the websocket as a protocol upgrade). It's preferable to fully mount the Proxy handler in the application. You can always run another handler before or after it if you need to modify the Conn.

[jbr]

querystring fix in #184 and released as [email protected]. I have the code that supports arbitrary rewriting stashed, but if the router+proxy behavior meets your needs, that's 100% the intended use case already. If you can think of further documentation that would help describe that, I'd appreciate even just a sketch — it's hard for me to know what's obvious.