Re: Proposed resolution for the STATUS100 issue

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