Re: (POST) new multi-phase and security

what the hell is this?

On Mon, 13 May 1996, Koen Holtman wrote:

> Paul Burchard:
> >
> >For that reason, I don't think HTTP agents should make any  
> >*automatic* retry decisions for POST, a method which can initiate  
> >arbitrary state changes.
> 
> Eek!  You are absolutely right!  An automatic retry of a
> non-idempotent method if it is not known whether the previous try was
> succesfull or not would be evil.  Especially because this could cause
> multiple POSTs on a 1.0 origin server (with CGI scripts designed for
> 1.0) in the following configuration:
> 
>  1.1 client --bad link-- 1.1 proxy --good link-- 1.0 origin server
> 
> It is bad enough that a bad link under 1.0 could cause a pizza order
> to disappear.  A bad 1.1 link causing *three* pizza's to be ordered
> would be an interesting new failure mode indeed!
> 
> Quick fix: the 13.4.1 text
> 
>   If an HTTP/1.1 client has seen an HTTP/1.1 or later response from the
>   server (clients SHOULD remember the version number of at least the most
>   recently used server), and it sees the connection close before receiving
>   any status from the server, the client SHOULD retry the request.  If the
>   client does retry the request,
>   .  it MUST first send the request headers,
>   .  and then MUST wait for the server to respond with either a 100
>      (continue) response, in which case the client should continue, or
>      with an error status.
> 
> 
> must be 
> 
>   If an HTTP/1.1 client has seen an HTTP/1.1 or later response from
>   the server (clients SHOULD remember the version number of at least
>   the most recently used server), and it sees the connection close
>   before receiving any status from the server, it should report the
>                                                ^^^^^^^^^^^^^^^^^^^^
>   error to the user.  If the user initiates a retry of the request,  
>   ^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   the client
>   ^^^^^^^^^^
>   .  MUST first send the request headers,
>     ^^
>   .  and then MUST wait for the server to respond with either a 100
>      (continue) response, in which case the client should continue, or
>      with an error status.
> 
> 
> >Paul Burchard   <burchard@cs.princeton.edu>
> 
> Koen.
> 
>

Received on Monday, 13 May 1996 13:09:31 UTC