- From: Jamie Lokier <jamie@shareable.org>
- Date: Mon, 21 Feb 2005 21:32:47 +0000
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: WebDAV <w3c-dist-auth@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
Geoffrey M Clemm wrote: > My main concern is that because of the popularity of SOAP, > many/most implementations fall into category 2b (i.e., "clueless"), > so a resource will say that it supports the POST operation, > but will actually fail it with some kind of 4xx response > because it cannot parse the body, or in the worst case, > will successfully parse the body and execute some potentially > harmful SOAP operation that was never intended by the client > (the client just wanted a subsidiary whose content was that body > to be created). .. > I'm rather surprised that clueless (e.g., SOAP :-) implementations > would parse the body of an unknown method (e.g., ADDMEMBER) > and treat it as if it were a POST call. Yes... I have seen numerous CGI implementations which parse a request as GET or POST, even if it has another method. > But even if a clueless implementation will try to parse the > body of an unknown method like ADDMEMBER, I assume it is very > unlikely that it would say that it supports the ADDMEMBER > method on that resource, so that at least would give the client > a way of avoiding the problem (i.e., by first asking the resource > if it supports the ADDMEMBER function, before attempting it). I think that's a reasonable assumption. But you should always try to avoid accessing unknown resources, even to query their capabilities: There are implementations where sending OPTIONS to them will be interpreted as a POST or stateful GET :) -- Jamie
Received on Monday, 21 February 2005 21:33:55 UTC