Re: Proxy support over AF_UNIX

[Ben Boeckel <mathstuf gmail com>]

On Fri, Jan 25, 2013 at 02:02:08 -0500, Ben Boeckel wrote:
> I'm interested in seeing support for AF_UNIX sockets as a proxy in
> libsoup. It seems as though most of the support needs to go into
> soup-address.c as well as possibly soup-socket.c (it appears as though
> much of the details are hidden in soup-address, but there may be
> something that I'm missing).
> 
> I have a first stab at the code done, but was unsure of how to
> conditionalize its support properly. Based on the GSocketAddress docs,
> using GLIB_SYSDEF_AF_UNIX seems like a decent approach. I have yet to
> write a test for it, but none of the existing tests fail (except apache
> which I don't have installed).

I have added support in SoupAddress, but it looks like I need to be able
to plumb through a SoupAddress through to use rather than trying to
parse a UNIX socket from a URI (which has seemed to get no real
standardization[1]). However, I am not all that familiar with glib-style
code and flow control is really hard to follow since it's a big maze of
function tables and such. It looks as though SoupConnection would be
where the SoupAddress override would be required, but I don't know how
best to get a SoupAddress to it. Currently, I see the following options
(in decreasing order of preference):

  - a SoupProxyConnector feature interface (with a
    SoupProxyConnectorUnix implementation) which makes the UNIX socket
    connection to the remote if available (might be overkill, but it
    avoids adding properties for platforms which don't support AF_UNIX
    anyways); or
  - add support for 'unix' as the proxy protocol (there are lots of
    hard-coded checks for 'http') via PROXY_URI special cased parsing
    (looks to be a lot of code that would need touched and if some other
    AF_* comes along, the same might need to be done for it); or
  - add a SoupAddress property to SoupProxyResolver (and an associated
    property for SoupSession) which would be used rather than making a
    connection based on the SoupURI parsing (a little messy and keeping
    the PROXY_URI properties in sync might be a nightmare); or
  - custom URI parsing (e.g., http://%2Ftmp%2Fproxy.socket/, but it's
    sure to be nonstandard no matter how it's done)?

Is there some other approach I'm missing that would be better?

Thanks,

--Ben

[1]http://curl.haxx.se/mail/lib-2008-04/0279.html