[
Lists Home |
Date Index |
Thread Index
]
> 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
|
