Laurens Holst wrote:
I don’t really see how POST is less harmful than DELETE. POST (if used
in a REST-y way) can be used to wreak serious havoc (e.g. spam messages,
overload server data capacity, post viruses, adding new super user
accounts for the hacker, change settings such as passwords, influence
poll results).
Additionally, there are a great number of sites that are using the HTTP
POST method for operations that would be more suitable for PUT and
DELETE. The reason that this happens is probably HTML’s fault, because
it only supports GET and POST, crippling the functionality that HTTP
provides. Non-REST webservices protocols such as XML-RPC and SOAP also
exclusively use POST.
If XDR only supports GET and POST, it encourages sites to use POST to
implement delete functionality and abuse the HTTP protocol because that
is the only way they can get the functionality they desire to work.
Basically, you’re boycotting REST in favour of SOAP.
So, I do not see much benefit in the decision to disallow DELETE but
allowing POST.
As a matter of fact, it would be harmful.
I don’t think you’re really keeping users very safe that way. To quote
an example, PHP is by default configured to send session credentials
entirely through sessionID link parameters when cookies are not
available, and thus don’t need cookies or authentication headers. And on
many sites (e.g. phpBB-based forums), communication with the server
(including deletion) happens exclusively through GET and POST requests.
XDR’s restrictions on methods and credentials will not do these sites
any good. Rather, they encourage even more sites to work around the
restrictions.
Additionally, if you really want to keep sites safe in this manner, you
should disallow cross-site POST requests for both XDR and HTML forms.
Otherwise, there is already a breach in the safety, POST is equally
suitable for ‘public’ data as DELETE and PUT are. You should allow those
methods, so that developers can at least provide a proper REST API and
are not forced to overload POST like XML-RPC and SOAP and friends do.
Absolutely.
Then create a whitelist, with at least the Accept-* headers on it. They
are clearly defined, and it is doubtful that they are used in a
different manner than described. The use cases are clear and plenty.
Correct.
I don’t think it is up to Microsoft to decide that content negotiation
is useless and that part of HTTP should not be supported even though it
poses no security risk. Part of the reason that content type negotiation
is reasonably uncommon in the wild is partially because of mediocre
support by user agents. By the way, content language and content
encoding negotiation is pretty common, actually.
Content type negotiation is very useful and I think a very nice feature
of HTTP, offering different ‘views’ (e.g. RSS or RDF, SVG or PNG) of the
same content. With XHR it was finally possible to use content type
negotiation in a good way in browsers, please don’t break it again in XDR.
Yes.
Not that it really matters -- even if Conneg wasn't useful, it's always
bad if specs start profiling the base protocol without very good reasons.
...
BR, Julian
