RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

> No, it shows where ignorance of the Web architecture can lead any
group
> of people to design a solution that breaks it instead of becoming part
> of it.  If you told people the truth about what will happen to SOAP
over
> HTTP as soon as firewalls are upgraded to defend against them, those
> customers wouldn't allow that technology in the door.

Well, my personal experience has been with customers who have upgraded
their firewalls specifically to enable SOAP packets to more efficiently
flow.  I suppose that some customers could be scared into inaction by
enough FUD, but that doesn't seem to be the case yet.  It would be a
shame to see people's personal opinions about "web architecture" spill
over into personality politics and FUD-mongering.  It would be a shame,
but I don't think it would have much impact on the adoption of SOAP.  I
am confident that the members of tag are mature enough to work out these
issues amongst themselves and come to consensus without causing
unnecessary polarization and politicization of the industry.

I *can* say, from firsthand experience, that many companies instituted
policies in the early days of the web by which they blocked *all* port
80 traffic from their networks.  This is because they became very
alarmed at the way that people were using POST to hook up to arbitrary
code.  And do you know what?  They *still* block all incoming port 80
traffic.  Most corporate IT security shops will *never* trust port 80
traffic to anything but their DMZs, because they know that they cannot
trust POST.

On the other hand, businesses know that they can filter SOAP messages at
a much more granular level, and they know that SOAP messages identify
themselves clearly, unlike the widespread generic abuse of POST.  POST
is the Trojan horse that businesses are afraid of.  It is sheer
duplicity to try to redirect people's attention to something far more
transparent and manageable like SOAP.

We all agree what the "good" use of POST is.  But it is the worst kind
of revisionist history to say that this use of POST was ever agreed upon
by any implementers or users -- it has always and will always exist only
in our imaginations.  You may claim that this use of POST was
fundamental to the original specs, but obviously the original spec was
loose enough to allow people to completely ignore the intentions and
abuse the heck out of POST.  POST abuse is de-facto standard, and I
blame it entirely on the POST specification.  Second to the POST spec, I
blame the original NCSA-HTTPD CGI samples that seduced people down the
road to ruin.  Considering that the current situation was created by the
original specs and the first web servers, there is something distinctly
Quixotic about someone trying to "fix" POST abuse at this point in the
game.

I would also point out that POST abuse probably had a lot to do with the
success of "the web" as we know it today.  Certainly "the largest
creation of wealth in the history of mankind" turned out to be a dream,
but places like Amazon.com, priceline.com, etc. have touched many lives.
Would Amazon or Priceline have ever deployed without POST "abuse"?  I
doubt it.  You may feel that the entire success of the web was due to
people following the principles that you retrospectively outlined in
your thesis paper, but you have to admit that people have been ignoring
your advice about POST for about 3 billion pages now, and things are
working just fine.

And if you are really concerned about POST abuse, then why not pose some
constructive suggestions about how to deal with it?  I think if anyone
sat down and tried to come up with a plan to reduce the abuse of POST
and clear the way for a semantic web, SOAP would be a significant part
of the solution.

Regards,
Joshua

Received on Wednesday, 24 April 2002 01:03:38 UTC