RE: Issues 12 & 192 (long)

Granting that I have never been the truest of believers in "chameleon", I 
find Larry's analysis convincing.  If I understand, he's advocating a 
practical approach, which I take to be:

* Admit that we're layering one protocol on another, not in some sense 
"extending".   That's true for HTTP on TCP and for SOAP on HTTP (I know 
Mark B. disagrees). 

* Make a best effort to use the services of the lower level in the manner 
appropriate to that lower layer, which may or may not be a direct 
reflection of upper layer semantics.    Close a connection at the TCP 
level when you're done with it, which may or may not be when this or that 
aspect of your HTTP activity completes.  For SOAP on HTTP, choose the HTTP 
status code most likely to keep the HTTP implementations happy...Larry 
suggests that may be 200, even for a SOAP fault. 

So it's not quite tunneling.  You are taking some trouble to reflect what 
you know in the upper layer, but only in the manner that best helps the 
lower layer.  If it's time to close the stream, you do close it.  If a 500 
status code will make more sense at the HTTP layer, you don't blindly send 
a 200.  True tunneling would imply that the status code is necessarily 
independent of the SOAP contents.    I hear Larry to say:  consider the 
fact that the SOAP message is a fault, but don't leap to the conclusion 
that 200 is the wrong status code for it.

If I've understood correctly, I think Larry has articulated the balance 
that I've been trying to express right along in this discussion.  If so, 
thank you (well, thank you anyway!)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Larry Masinter" <LMM@acm.org>
Sent by: xml-dist-app-request@w3.org
03/31/2002 01:39 PM
Please respond to LMM

 
        To:     <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Issues 12 & 192 (long)


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 Tuesday, 2 April 2002 19:18:20 UTC