[
Lists Home |
Date Index |
Thread Index
]
Rich,
What you have written is an excellent description of the mismatch between the
http protocol (developed for page information) and the requirements of business
messaging.
The two are significantly different and patching http to do the job doesn't
always give the best results. It's kindof like taking a ford focus, dropping a
v8 in it, adding a body lift kit and 4wd and expecting it to do a fantastic job
off-road. It's just never going to happen...
The only real options are to use a proprietory solution (ie Biztalk, MQ,
Sterling etc) or go back to good old EDI.
What do you think of ebxml? isn't that supposed to do what you are talking
about?
Quoting Rich Salz <rsalz@datapower.com>:
> 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
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
