Re: A tale of two bindings

> > I'm not sure why a) would be necessary.  It's part of what's
> > required to do b), but I don't see it as useful by itself.
> 
> 4xx or 5xx status codes may be generated by software other than the
> SOAP processor; either the HTTP implementation of the sender, or an
> HTTP intermediary.

Absolutely.  That's perfectly ok.  "400" means "400" independant
of *why* the 400 was returned.  That there may or may not be
more information for me in the body says nothing about the
utility of being able to take action based only on the 400.

> > Also, the HTTP response status code gives you some information
> > about the nature of the fault, just not as much as the body
> > would.  But it would be enough information to take action in
> > many cases.
> 
> Exactly - and that action may be based on false assumptions.

Now we're back to our original argument, that you believe that
400 or 500 should not be used for SOAP because HTTP's processing
model doesn't extend beyond the HTTP server (IIRC).

I've written web apps that return 4xx status codes before,
because they manage their own set of resources that my web
server knows nothing about.  So the "server" in this case
isn't the web server, it's the app bound to some URL path.
How is this any different than a SOAP app bound to a web
server via dispatch on a MIME media type?  Why can it not
return a 400 when the request to it is bad?

> > How can anybody misuse a *subset* of the information that would be
> > available to you if you cracked open the body?  It's not like you're
> > going to find anything in there that would tell you that the HTTP
> > response code you saw was the wrong one.
> 
> Turn it around - an HTTP implementation that isn't aware of SOAP
> semantics may make assumptions based on the status code of the
> message. 

If it couldn't, I wouldn't be suggesting this.
(see argument above).

> > [...] we need to give them a way to identify (so it can be turned
> > off) any SOAP tunneling.
> 
> Content-Type. Of course, there are no guarantees that all SOAP-like
> messages sent by HTTP are flagged as such, but that's not our problem
> - it's a problem with filtering based on hints and heuristics in
> general.

I agree.  Content-Type filtering *may* not be sufficient (depends on
other requirements), but it's better than Rich's (apparent) position
that hiding it completely is fine (or perhaps he was just playing
Devil's advocate, dunno).

Also, if other SOAP-like messages aren't flagged as such, IT
departments shouldn't allow people to install software behind the
firewall that recognizes undocumented dispatch mechanisms.  That's
just asking for trouble.

MB

Received on Friday, 27 July 2001 14:10:20 UTC