Is HTTP Synchronous?

People often say that HTTP is a synchronous, not asyncronous protocol. The often offer SMTP as an example of an asynchronous protocol. If SMTP is synchronous, HTTP is too. If SMTP is asynchronous, HTTP is too.

Both of these protocols are synchronous in the sense that a client connects to a server and it submits some information and waits for a response. SMTP is actually a much more "chatty" protocol than HTTP:

            S: MAIL FROM:<Smith@Alpha.ARPA>
            R: 250 OK

            S: RCPT TO:<Jones@Beta.ARPA>
            R: 250 OK

            S: RCPT TO:<Green@Beta.ARPA>
            R: 550 No such user here

            S: RCPT TO:<Brown@Beta.ARPA>
            R: 250 OK

            S: DATA
            R: 354 Start mail input; end with <CRLF>.<CRLF>
            S: Blah blah blah...
            S: ...etc. etc. etc.
            S: <CRLF>.<CRLF>
            R: 250 OK

If the other server is slow your SMTP message send will be slow also. If your client-side process is waiting for the OK then it will hang, just as it would with HTTP. That's why scalable clients and servers are typically implemented in an asynchronous fashion, whether or not the actual protocol is synchronous or asynchronous.

Now the SMTP software has the nice feature that it will take your message and forward it to someone else, using a different SMTP server. HTTP software could do that too. Part of what SMTP has that HTTP does not (built-in) is explicit message routing. It is really easy to build this on top of HTTP but it is not part of HTTP. If we were using HTTP for a mail system of course we would add routing (but not asynch). Any system that does an HTTP to mail gateway does do some routing so it is clear that this isn't hard. It just isn't standardized. So that's a real difference between HTTP and SMTP, but it isn't about asynchronous versus synchronous.

The SMTP software also has a nice feature that it will keep trying to deliver the message even if the other service isn't online. This is store and forward. It's just a feature of the SMTP software, not of the protocol spoken between the client and the server. HTTP software could implement this just as easily and I've implemented HTTP software that does! It is no harder to write or maintain than the equivalent SMTP software.

SMTP software also has the nice feature that it will contact you if it can't deliver your message (though there is no way to ask it if it did!). This is a "callback." Callbacks are very common in HTTP systems where both ends of the system are HTTP servers. For instance, you can register a channel with the Meerkat RSS indexing service and it will "call you back" once a day (or regularly, anyhow) to check for new information. That's a callback. Dave Winer proposes a callback be built-into RSS.

All you need for a callback is for the client to register a callback address with the server and get a message later. There is no magic involved! All SMTP software implements this callback mechanism and some (but not all) HTTP software does also.

Store and forward is not that useful without callbacks (otherwise how will you know if your message got delivered?). So callbacks are an important important precondition for HTTP store and forward. Why are HTTP callbacks rare?

• SMTP had callbacks before there was an HTTP so people are used to that.
• SMTP-delivered callbacks are compatible with existing mail clients. Of course this hardly matters for machine-to-machine applications but I guess it is nice to have a nice human-oriented user interface for debugging.
• HTTP has four main methods, GET, PUT, POST and DELETE. In most people's minds, HTTP "defaults" to GET in that GET is the simplest method to invoke in HTTP. SMTP, on the other hand, basically defaults to "POST". Therefore, people tend to use HTTP for GET callbacks and SMTP for POST ones. Meerkat's callback is logically a GET. Dave Winer's "Web bugs in XML" is logically a POST.
• If you use HTTP for GET and SMTP for POST then you don't have to say what method you are trying to invoke. SMTP can "only" do POST so using "mailto:" implies POST callback. HTTP strongly defaults to GET so using "http:" implies GET callback.
• HTTP doesn't have a standardized way to ask for callbacks. SMTP doesn't either, but the failure callbacks it provides are automatically implied by the act of sending mail. For HTTP it would be logical thing to ask for callbacks on resource changes. Here's a proposal for how you might standardize this. Here is another very similar one.

I would agree that HTTP is not as "asynchronous" as protocols that do not allow responses to requests. In those protocols you must build synchronous interfaces on top of the asynchronous infrastructure and in HTTP or SMTP you build the asynchronous infrastructure on top of the synchronous one. I can't see any killer advantage either way. I also don't see any benefit to defining specially asynchronous protocols rather than just using HTTP in an asynchronous manner.