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