File upload is not a safe operation. In general, most applications that involve user-supplied data being supplied to the server are not safe. The only exception is when the information is in the form of generalized query parameters, for which there is a trade-off between GET and POST that usually involves the size of the parameter content. GET is only desirable for those cases where the parameters can be expressed as a meaningful URI.

As I mentioned on the conference call, it would be far more effective to tease out the principles of the Web and define those, rather than express edicts about the use of HTTP. The fact of the matter is that most CGI scripts are not HTTP compliant. Most CGI scripts, in fact, provide interfaces to applications that suck. The "G" stands for Gateway. What people should realize is not that "CGI scripts should be banned", but rather that if the CGI script is written such that it behaves like a proper Web interface, then it won't suck. The point is to describe to developers the ways in which an interface can be better implemented on the Web. REST is not the easiest way to provide an interface on the Web. In fact, doing it right requires fairly sophisticated software. CGI makes life easy for programmers. REST-like operation makes life easy for users and content maintainers.

The problem with SOAP is that it tries to escape from the Web interface. It deliberately attempts to suck, mostly because it is deliberately trying to supplant CGI-like applications rather than Web-like applications. It is simply a waste of time for folks to say that "HTTP allows this because I've seen it used by this common CGI script." If we thought that sucky CGI scripts were the basis for good Web architectures, then we wouldn't have needed a Gateway Interface to implement them.

In order for SOAP-ng to succeed as a Web protocol, it needs to start behaving like it is part of the Web. That means, among other things, that it should stop trying to encapsulate all sorts of actions under an object-specific interface. It needs to limit its object-specific behavior to those situations in which object-specific behavior is actually desirable. If it does not do so, then it is not using URI as the basis for resource identification, and therefore it is no more part of the Web than SMTP.

I think that is stretching it. The HTTP-WG never reached any conclusion on the topic. The Safe header field was not implemented because it is utterly pointless to know whether or not a message is safe *after* it has been invoked. We already have other means to mark whether or not content can be cached, and caches won't use anything other than a URI and simple header field content as a cache key.

Cheers,

Roy T. Fielding, Chairman, The Apache Software Foundation (fiel...@apache.org) <http://www.apache.org/>

Chief Scientist, Day Software 2 Corporate Plaza, Suite 150 Newport Beach, CA 92660-7929 fax:+1.949.644.5064 (roy....@day.com) <http://www.day.com/>