[Ietf-caldav] Re: draft-reschke-http-addmember-00

[Julian Reschke <[e-mail]>]

Jamie Lokier wrote:
> 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,

I'm not sure what your point is. Of course if a server mishaves that 
way, a client accessing it may cause problems. But that's the problem of 
the server, and I don't think there's anything we can do about that when 
discussing HTTP based protocols.

What am I missing?

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]