[
Lists Home |
Date Index |
Thread Index
]
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@interx.com http://www.interx.com/
|
