Cart
[Home] [By Thread] [By Date] [Recent Entries]
Paul Prescod wrote, > You misunderstood me. I didn't ask whether retry is a protocol issue > or an application issue. I asked whether it is a protocol issue or a > software (implementation of protocol) issue? Couldn't I write an > HTTP client that DOES retry and an SMTP implementation that does NOT > do retry? You could. But the only retry mechanisms mentioned in RFC 2616 are concerned exclusively with transient network failures and some of the more irritatingly non-deterministic aspects of persistent connections and piplining. Disconnected operation is a world away from transient failures and race conditions, and a retry protocol suitable for the one isn't obviously suitable for the other. You could design retry mechanism for disconnected operation on top of HTTP, but that wouldn't be either a part of the HTTP protocol or an implementation of it (tho' it might be part of a layered protocol, or an HTTP application). > Retry on GETs and PUTs are safe because both are idempotent. It > takes a wee bit more effort on the part of the application creator > to make a re-tryable POST service. RFC 2616 says no, 8.1.4 Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The reference to human operators or semantic understanding of the application shows that this sort of retry behaviour is beyond the scope of HTTP as a protocol (tho', again, it might be part of a layered protocol, or an HTTP application). Cheers, Miles -- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK msabin@i... http://www.interx.com/
|
