Michal Marek wrote:
> Nikolai Kondrashov wrote:
>
>> Daniel Stenberg wrote:
>> > A new option seems like the least kludgey way to me.
>> I think the option is not a bad way to do it and seems a bit faster to
>> implement. Although I'm afraid it will add more un-orthogonality to the
>> interface and implementation and will look more like a hack. But it is still
>> better than messing with HTTP URLs.
>>
>
> You are right. I initially though that embedding the socket path into
> the URL would be "cool", that's why I suggested defining an URL scheme
> for this on #curl. But now I tend to agree that an extra option would be
> easier to use (compared to the the URL-encoding needed otherwise). Bart,
> what's you opinion on this?
>

I agree that an extra option seems like the cleanest approach thus far.
I have found examples of applications that invent new schemes, but these
are always specific to a certain application. I also found an example
of an application that uses a non-numeric port field to encode the path
to the unix socket.

As far as vhosting is concerned, I don't believe that any of the
applications that I have in mind for this do vhosting, but at least one
of them does require the Host: header to to be present, as this is
required by the RFC for HTTP/1.1.

I'm familiar with three WBEM (CIM-XML over HTTP) client libraries that
support connecting to a unix socket. Each of these expose the
functionality to the client application in different ways. One uses a
separate function call to establish a connection to the unix socket vs.
a TCP socket. Others use home brewed URL schemes, or even the absence
of a scheme to imply HTTP over the unix socket. Now I need to add the
capability to connect to a unix socket to a fourth WBEM client library,
and this library uses libcurl. Within the WBEM client library, I'll
have to come up with a way to allow the client application to request a
connection to a unix socket. I'll have to have a separate API for this,
or encode it in the URL (and then document this). Then, I need a way to
pass this information to libcurl. It's less important to me how I have
to give this information to libcurl, as long as I can do it.

I guess it would be kind of nice if the path to the unix socket was
encoded in the URL for libcurl, as this would require no changes to the
WBEM client library. However, if we can't come up with a way to do this
that feels good to the libcurl community, I'm totally fine with
extending the API of the WBEM client library, or inventing some
application-specific way of encoding the path in the URL, and then doing
some URL parsing in the WBEM client library prior to invoking libcurl.

Hope this helps.
Received on 2008-04-14