On the libcurl list the discussion popped up how to best add support to do HTTP over unix domain sockets instead of TCP/IP and the discussion took off trying to figure out how to specify this the best way from an application’s point of view.
What’s your take on this?
Hi, by could use a character from the sub-delim set in RFC3986 somewhere in the host part of the URL. Such an URL could not be confused with a regular http url. It would currently not be a valid http url, but by supporting this, common practise could make it compatible to a future http revision since it does not break anything that currently works, and it would be compliant with RFC3986.
Example: Let’s say the socket is /tmp/daemon.socket, and this supplies a path “service”. This could be specified as http://socket=%2Ftmp%2Fdaemon.socket/service
Here the equals sign belongs to sub-delim, which is valid here. Apart from being being a valid URL, it also quite self descriptive. It also follows the same pattern as some other schemes, such as Diameter (see http://en.wikipedia.org/wiki/URI_scheme)
See also my post to uri@w3.org about this: http://lists.w3.org/Archives/Public/uri/2008Oct/0000.html
Claes
Yeah, but in practice there’s rarely a case where you want to be able to randomly select a URL for a unix domain anyway
The way libcurl currently supports this (kind of the outcome we came to after I posted this article) is simply by allowing the app to control how the socket is created and thus it can hide for libcurl what kind of socket it actually uses. See this:
http://curl.haxx.se/mail/lib-2008-04/0358.html
That seems to be the case.. and I guess it is that way because there is no standardized way to connect to sockets with http. Very few clients support it, so very few services are implemented this way. Chicken and egg problem, which leads to no pressure for standardization.
If socket-based http was widespread, and common browsers supported this way to connect to local services, I think it would be a good interface for applications that by neccessity have to be local. It would offer an alternative way in the “toolkit wars”. And it would be simple to provide a “clickable interface” for simple scripts and stuff like that. Well well..