PUT

I'd like to generate some discussion on the problems recently
discovered with PUT (and large POSTs).  Our server implements PUT, but
I unfortunately downloaded a copy of the protocol before the problems
were discovered.  I then managed to independantly trip over the same
problems.  About a week ago, I decided to get the latest copy of the
spec, and saw my problems alluded to.  My timing was horrible.  :-)

I would emphasaize the problem even more than is noted in the Aug 3
draft-ietf-http-v10-spec-01 section 5.2.4, to say the protocol as it
stands -cannot handle- all potential error conditions.  Prior
negotiation helps with a few cases, but -not all of them-.

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.)

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.
2) Failure status is returned as soon as a failure occurs.  Success
   status is never returned until the very end of the entire
   transaction.
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.

Option 1 isn't good, because it may leave the client with the impression
that a transfer was successful, when it wasn't.  As a hack, the client
could be required to "call back" and ask about the previous
transaction (via message-id?) before it is accepted.

Option 2 requires much hairier client and server code.  It seems to me
that everything would require nonblocking i/o, in order to constantly
check to see if reading or writing is possible.  Timing issues
suddenly become of concern, because the server may be in the process
of rejecting the transfer, but the client is assuming that everything
is okay.

Option 3 is just a hack.  Having the server eat a 10Mb upload before
saying "unauthorized" is evil.  

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.

The only acceptable solution here seems to be to have two status
messages returned.  I don't know how this would work when
content-length isn't sent, but non-packetized streamed data has always
struck me as pretty nasty anyway.

The PUT command is integral to our requirements, so I am desperate to
get a workable solution into 1.1.

Any thoughts?  Hypermail pointers for me?

Thanks!

-Roger

Roger Gonzalez                    NetCentric Corporation
rg@server.net                     56 Rogers Street
home   (617) 646-0028             Cambridge, MA 02142
mobile (617) 755-0635             work (617) 868-8600



60 09 3A EE FE 6A 1E CC   -pgp-   B7 F7 6B 0F 00 1D 01 C7

Received on Tuesday, 26 September 1995 08:25:41 UTC