[
Lists Home |
Date Index |
Thread Index
]
Miles Sabin wrote:
>
> 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.
But that's exactly my point. A web client that retries GETs is not using
a different protocol than HTTP. It is just using HTTP in a slightly
smarter way than other web client.
> 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.
I'm not suggesting a retry protocol. I'm suggesting that applications
retry. (for GETs and PUTs the HTTP library could do it automatically)
> ... 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.
I think that what I said corresponds to what the spec says. I said that
it must be done at the application layer. As far as I know, SMTP is the
same. What web-deployed protocol would be better? How would (for
example) SOAP be better?
> 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).
We're in agreement on that. My point is that retry is not in any sense
at odds with HTTP. And it is no harder to add to HTTP than to SMTP or
SOAP or ...
Paul Prescod
|
