Cart
[Home] [By Thread] [By Date] [Recent Entries]
> O(N) beats O(NlogN) every day of the week, industry concensus > notwithstanding. All other points of evaluation - some of which > I'll admit are in Web services' favour - are insignificant in > comparison. Gee, I don't know how to characterize this claim -- hubris? delusional? rhetorical device, plain old flaming? Everything else is insignificant? Really, everything? In all cases and at all time? Let's see if I can poke some holes in that. HTTP adds no reliability on top of TCP and is therefore only as reliable as TCP. For example, a router (or proxy, or load balancer or Akamai, or whatever) sits between the HTTP client and origin server. The client sends his request, the server process it, and starts to send the reply. If it's a short reply it might fit into a single IP packet. The network hardware goes down after the server has sent the packet, but before it hit the gateway. Now what? The client see that the TCP link went away, but has no idea if his request got through. So he hits SUBMIT again. :) The server sees that the TCP link got shut down, but by then the response could be down in the kernel so the HTTP engine has no idea, and even if if the server *is* careful to properly shutdown the socket and check the return value of close() (closesocket() to you winsock jocks), and even if the server *has* a full copy of the reponse lying around, there is no way in HTTP (nor, I think, in REST at all) for the server to re-send its response over a new TCP link. Over on the client side. Hitting SUBMIT again, hope it works this time, and hope that the back-office system will see that this is a "duplicate" and just re-send my confirmation. Of course, doing that violates REST. Or we just let the purchase go through a second time and then deal with the Credit Card company to get a refund. But what if the Credit Card company is building its back office around HTTP and REST? They *can't* resubmit and let someone else work it out. :) Note that I'm not talking about transactions, rollback, etc., I just want to know if the damn message got there and what the answer was. I'd also like to avoid message replay. Do you want E911 or other emergency services (i.e., your power grid) to be based on this infrastructure? I know Len's worried about these kinds of things. And I wouldn't call police dispatch or on-line power grid management insignificant. HTTP has no way to provide end-to-end security of the Request URI. That means you can't do a GET and have any cryptographically based way to be sure that (a) the URI wasn't modified in-flight; and (b) that nobody else will see it (i.e., signing and encryption). SSL/TLS is only hop-by-hop. If there are any proxies or loadbalancers in the path, at least some of them will get the plaintext. For security reasons, then, you have to put all the data into the HTTP request body, which means using PUT or POST. It's unfortunate that securely getting a resource requires a PUT, but I suppose for architectural purity we can live with that. But I think most request/response exchanges anticipated for Web Services aren't idempotent (i.e., not safe to resubmit), so that means using POST. Once you use POST, most of the benefits of the HTTP infrastructure (caching, etc), and most of the nicer properties of REST, go away. They just aren't there. Because, as I tried to explain in the previous two paragraphs, your POST request body has to at least include a copy of the Request URI in order to get end-to-end security. And what if the message involves multiple resources on the server, like a transfer of funds bvetween two accounts -- whose number goes into the URI? Suppose it's not financial, but medical data in the US or data covered by European privacy laws, etc. The URI probably cannot contain identifying information. (If there were a way to encrypt the URI, it could be. But there's no standard.) For all those reasons, then, you might as well use a something generic in the Request URI and put all the information to identify the resource into the request body. Taken together, I think HTTP and REST fail to meet the needs of some very real-world systems. I think I'm basing this note on first-hand knowledge, but if your paragraph is to be believed, I must be making it all up. So, for those of you who read this far, "Never mind." :) /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
|
