Re: Proxy support over AF_UNIX

[Ben Boeckel <mathstuf gmail com>]

On Tue, Feb 26, 2013 at 22:30:37 +0100, Dan Winship wrote:
> On 02/26/2013 05:42 AM, Ben Boeckel wrote:
> Yeah, I didn't want to commit it right before the last release, since it
> could easily have broken things. And then I've been travelling for work
> since then so I haven't gotten around to committing it yet...

Sounds good. Just wanted to make sure I wasn't waiting for 2.44.0.

> > So far, I have a GProxy
> > subclass which, based off of GSocks4aProxy, needs to do pretty much
> > nothing in GProxy::connect other than return the given GIOStream.
>
> No. The SOCKS proxies do that because, like I said above, all they need
> to do is do some initial setup on the connection, but then the caller
> uses the original connection normally.
>
> In your case, you want to create an appropriate GUnixConnection in
> ::connect, and return that instead.

Ah, ok.

> Yeah, so this is messy, because it's not a use case we'd thought about
> when we wrote this originally. For SOCKS and HTTP proxies, when you
> connect via a proxy, the first step is still to create a TCP connection;
> you're just creating a TCP connection to the proxy server rather than to
> the destination server. So GSocketClient will always start by creating a
> TCP connection to the host and port identified in the proxy URI returned
> by the GProxyResolver, and then it passes that GSocketConnection to
> g_proxy_connect().

I imagine adding a 'path' attribute to GProxyAddress is out of the
question. Not sure how to serialize/deserialize that into a URI anyways.
I'd have to see what curl does for that.

> So you have to allow GSocketClient to make a TCP connection to
> *somewhere*... one possibility would be for the GProxyResolver to return
> a proxy URI containing the same host and port as the original request.
> Then GSocketClient would connect to that host/port and pass the
> GSocketConnection to your GProxy::connection, and then from there, you
> could create your GUnixConnection, and then extract the file descriptor
> from the original GSocketConnection and pass it over the unix socket...
> although this gets tricky because the GSocketConnection is going to want
> to close the socket when it's freed, so you'd have to dup() the fd or
> something. Blah.
>
> Maybe it would be easier to just use a TCP connection to localhost
> rather than using a unix socket? So in that case, the proxy resolver
> would return my-proxy-protocol://127.0.0.1:port/, and connect to your
> proxy process that way, and then GProxy::connect would pass whatever
> info the process on the other side needed, much like the SOCKS proxies do.

That won't work with what I was envisioning since each instance of uzbl
would have its own proxy. Plus, there's no way over TCP to ensure that
some other user isn't piggy-backing on the proxy connection.

One of the end goals is to implement ad blocking, header mangling, etc.
via the proxy, so connecting to the end server wouldn't really mesh well
with that.

Since the internals need *somewhere* to connect to, maybe a per-user TCP
socket can listen for the proxy URI which can then be dropped safely.
I'll have to test to see what kind of data is needed between the GProxy
implementation and the proxy.

> Calling
>
>     g_io_extension_point_implement (G_PROXY_EXTENSION_POINT_NAME,
>                                     FOO_TYPE_PROXY,
>                                     "foo",
>                                     0);
>
> tells glib that the GType FOO_TYPE_PROXY implements the "foo" proxy
> scheme, so that if your GProxyResolver returns a "foo://..." URI,
> GSocketClient will instantiate a FooProxy to connect to it.

Okay, I figured that's what the call did. I assume it's on-library-load
magic?

Thanks,

--Ben