W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: Issues 12 & 192 (long)

From: Larry Masinter <LMM@acm.org>
Date: Sun, 31 Mar 2002 10:39:30 -0800
To: <xml-dist-app@w3.org>
Message-ID: <000001c1d8e3$64fca7e0$6ace8642@larrypad>
I think I originated this issue two years ago
http://discuss.develop.com/archives/wa.exe?A2=ind0004&L=soap&F=&S=&P=317
74
and that the arguments haven't changed much. I worry
about whether "XML Protocol" can ever converge when
issues remain open and active for two years with no
progress.


Here's another analogy:

HTTP is layered on TCP/IP. TCP/IP has its own ways of signalling.
For example, TCP/IP can signal a close of connection. HTTP was
designed so that it could also layer over other byte-stream
protocols; at the time, there was some interest in HTTP-over-DECNet,
for example.

HTTP 0.9 had an unfortunate design: it used close-of-connection
at the TCP layer to signal end-of-data at the HTTP layer.
Unfortunately, this led to serious problems, because the
application layer, when it got a close-of-connection, couldn't
distinguish between the connection closing because there
wasn't any data, or the connection closing for some other
reason -- a break in the gateway, some other interference of
an intermediary, etc.

This problem wasn't understood at first, because in ordinary
operation, most of the time, using close-of-connection for
end-of-data was fine.

HTTP/1.0 tried to fix the problems by adding content-length
and saying it was the determining factor, and HTTP/1.1
added chunked encoding to fix the problems with using
content-length (that content couldn't be transmitted as
generated even when the length was known.)

In the case of SOAP-over-HTTP, you've gone beyond relying
on the 500 Server Error to signal anything having to do
with SOAP faults, and now you're arguing about whether
it's reasonable to ALSO use "500 server error" in the
cases where the SOAP layer is signalling a SOAP fault.

By analogy, this is analogous to the question about whether
a HTTP server may ALSO close the connection when it's still
sending the chunked data. The answer wasn't based on
first principles about signalling twice (once at the
HTTP layer and once at the TCP layer) but about whether
the signal at the TCP layer (connection close) was useful
for the TCP layer (that the connection wasn't going to be
used any more.)

In the case of SOAP over HTTP, the arguments for the utility
of "500 Server Error" instead of "200 OK" for SOAP faults
haven't been convincing -- where's the utility? Mark Baker
came up with the (IMO nonsensical) example of a
"HTTP proxy tracking successful purchases", but for the
most part, a "500 Server Error" would seem to interfere
more than it would help.

In fact, the analogy is a pretty good one: you shouldn't
close the TCP connection if you want to send more data
soon to the same partner. "connection close" is a signal
for no further communication. Similarly, "500 Server Error"
signals an unrecoverable error at the HTTP layer, and
would interfere with further transactions with the same
server, at least in some implementations.
Received on Sunday, 31 March 2002 13:40:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT