Re: PUT

>The basic problem seems to be that there is status information that
>may need to be sent in response to the request (i.e. you need to
>authenticate, or you aren't allowed to write there, etc.), but there
>is also status information that may need to be sent at the end of the
>transfer (I ran out of disk space, your quota was exceeded, I didn't
>receive content-length bytes from you, the checksum didn't match,
>etc.)

Right -- we (W3C and John Mallery upstairs) came to the same conclusion
three months ago regarding the need for a two-phase PUT process.  This
is one of the (many) things which will appear in the initial HTTP/1.1
spec.  You will note that the 1.0 spec now contains a more detailed reference
to 1xx Informational responses.

>As it stands, this leaves a few options:
>
>1) Status is returned immediately after the request, and no
>   status is returned to signify the success of the entity transfer.

100 Continue  (or 401 Unauthorized, ...) will be returned as soon
as the request headers are received.

>2) Failure status is returned as soon as a failure occurs.  Success
>   status is never returned until the very end of the entire
>   transaction.

And it only works if the client is reading the input buffer during
the write process.  So, we will include two "success" responses in
the transmission -- the first being informational.  The client will
be required to wait a minimum amount of time (5 secs?) until a
response of some kind is returned before continuing with the body
transmission (or restarting the request with authorization).

At the same time, an OPTIONS method will be defined to allow a client
to ask about such things before doing them.

>3) All status is returned at the completion of the entire transaction.
>   The server is required to eat (and probably discard) any data the
>   client sends, even if it failed.

Which is current (HTTP/1.0) behavior -- it works just fine providing the
action has been pre-negotiated using out-of-band knowledge.

>I have tried all three options, more or less.  I didn't like any of
>them.  At worst, they leave partial files.  At best, I'm open to
>denial-of-service attacks.

No -- PUT-specific denial-of-service attacks are preventable by
restricting access, enforcing timeouts, and denying PUTs with
Content-Length > some limit.

>The only acceptable solution here seems to be to have two status
>messages returned.

Exactly.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Tuesday, 26 September 1995 14:10:46 UTC