SOAP messages require a body so the traditional HTTP GET message insufficient to convey a SOAP request. The solution is to use POST. Within HTTP, there are two sets of semantics associated with the HTTP method, cachability and side-effects. These two concepts are usually tied; messages that have no side-effects are safe to cache.
GET can carry headers that desribe what headers to look at when deciding if something is cachable. POST messages are defined to be uncachable. SOAP's use of POST removes and hope of caching the message. While some messages (updates and transmissions of data) are not cachable, some, like the Stock Quote example in the spec, are an excellent example of data that is cachable for some (limited) time. An obvious choice of a URL for this resource would be http://example.com//StockTicker/ibm which could easily be cached by existing infrastructure on the web.
Most queries may be recorded in the form of a URI and replayed by executing the default action, GET, on that URI. Bookmarking and passing someone a URI or good examples of this. There is a set of SOAP messages that could be characterized as queries. Transporting these messages over POST requests prevents them from being identified and and repeated via a URL. Again, encoding the parameters in a URL path or query string solves this problem.
Traditionally, an HTTP agent need not look at the the body in deciding whether and how to cache an object. This could change, but it implies a lot more effort on the part of proxies and is less scalable as messages may be arbitrarily large. A caching proxy would need to parse the POST body, extract SOAP extensions that defined the variants in the request, and index the reply message by those variants. Placing the variants in the URL or MIME headers is much more strait-forward. There is no need for parsing or extracting the variants.
An argument for using SOAP messages for queries is that an agent may use the header mechanism to stack in orthogonal extensions. For instance, the StockQuite example could be addended to have a header requesting a signature by a public key and have the result encrypted by the corresponding private key. This extension is a transformation that could be applied to many differenct requests. The result is also cachable in that the response document could be cached in a signed form just as well as it could be cached in a non-signed form.
Requesting this extension is analogous to requesting a transfer coding except that XML and namespaces are used to unambiguously identify the transformation, rather than the usual use of IANA for registries.
In order to map SOAP headers to HTTP headers, we must be able to use URNs to identify the same extensions in HTTP headers that we can in SOAP headers. HTTP Extensions is a mechanism that ties a set of HTTP headers to a URN so that agents my unabiguously identify headers in their domain and not worry about collisions with other domains. Mapping SOAP headers to HTTP extensions permits the agent to again use a GET to retrieve, for instance, http://exmaple.com/StockTicker/ibm.