- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 18 Jul 1997 21:04:27 +0200 (MET DST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul:
>
>Maurizio Codogno <mau@beatles.cselt.it> writes:
>
[Proposed text by Jeffrey Mogul:]
> If the request method is not idempotent, the
> client SHOULD NOT retry the request without user confirmation.
>
> I'd prefer a MUST NOT, especially in light of the following
> sentence. As far as I can parse English language, it would mean
> that either the user agent knows for sure that it is safe to retry
> the request or it warns the user.
>
>I've been given encouragement, by the working group, to avoid
>using MUST when SHOULD is sufficient.
The original text in 2068 had a MUST here:
the client SHOULD retry
the request without user interaction so long as the request method is
idempotent (see section 9.1.2); other methods MUST NOT be
^^^^
automatically retried, although user agents MAY offer a human
operator the choice of retrying the request..
and I would view changing this MUST to a SHOULD as a completely
unacceptable change in the protocol.
I *never* want proxies to take the initiative in retrying an
idempotent operation. It would be OK to dilute the MUST to a SHOULD
for user agents, but not for proxies. This would make the web
unsafe for ordering pizzas.
> In this case, it seems
>plausible that there may be some applications in which user
>confirmation is hard to obtain, and the risks associated with
>not finishing the request are less important than the risks
>associated with non-idempotency.
Applications in which the risks associated with not finishing the
request are less important than the risks associated with
non-idempotency should never use HTTP/1.1, because HTTP/1.1 allows
random parties to abort the transaction at any time.
>-Jeff
Koen.
Received on Friday, 18 July 1997 12:10:50 UTC