add :socket for --unix-socket

[zweifisch]

Hi @ewestbrook, there is :curl, which can be used to pass additional options to curl, so closing.

[ewestbrook]

Please reconsider? Some reasons to think about:

• Convenience and space; saves typing and text bulk in org-mode files, which can only serve to increase adoption of and satisfaction with this tool. #+BEGIN_SRC http :socket /socket is much cleaner, concise, and easier to remember than #+BEGIN_SRC http :curl --unix-socket /socket. The latter litters the org-mode file with essentially empty syntax.

• Backend flexibility. Any tool called ob-http should be able to switch backends as easily as possible, in the event someone wishes to use something other than curl in the future. Purpose-oriented parameters allow this most simply, while backend-specific parameters do not. Besides, offering this parameter certainly does not remove the :curl option, for those that enjoy it; it merely provides a much easier to remember, simpler, and more portable form for this parameter, for those who prefer that.

• Project naming convention. Why have any arguments other than :curl at all, then? Perhaps you should call it ob-curl rather than ob-http. (An honest point, if admittedly a bit snarky.)

[zweifisch]

Shared header arguments can be set using property drawers

** request demo
:properties:
:header-args: :curl --unix-socket /socket
:end:

I think http via unix-socket is rarely used, and event if we are going to add a header argument for that, it should be :unix-socket instead of :socket.

[ewestbrook]

I agree, :unix-socket is clearer. Done, and pushed to the same branch.

You're right, it's rarely used -- but I think that's only because few people know how great and how easy it is. The difference in performance due to overhead reduction is dramatic. There's no DNS round-trip, no SYN/ACK cycle, no network nonsense whatsoever under the hood. Just kernel memory buffers. It's absolutely amazing, the first time you feel it, especially if you make requests repeatedly in a loop.

(Side note: It's also why MySQL uses e.g. /var/run/mysqld.sock instead of 127.0.0.1 when you connect to localhost.)

I suggest you try it!

If you use nginx, it's as simple as this:

server {
    listen unix:/var/run/nginx.sock;
    location / { return 200; }
}

and then of course via ob-http you can

#+BEGIN_SRC http :pretty no :curl --socket /var/run/nginx.sock
GET http://localhost/
#+END_SRC

Note, the hostname in the authority position of the URL is what nginx receives in the Host: header (localhost in this case), but you can use anything, which makes it handy to configure a unix: listener for local testing right alongside the network listener server stanzas, and use the exact same URLs both ways.

You're also right about property drawers, which should also tidy things up. I should use those more.

No worries, regardless -- I'm using my own fork locally. I just thought you, and others, might enjoy the convenience. Many thanks for the great module either way.