Re: 'PUT' transaction reconsidered (was Re: two-phase send concerns )

On Wed, 27 Dec 1995, Jeffrey Mogul wrote:


> Would anyone like to argue that more than 25% of PUTs (and similar
> HTTP methods) are going to be rejected?  To me, this seems unlikely
> (most users will learn not to ask for things that the servers don't
> allow), but I don't have enough experience to know.

I would add to the assumptions that support Jeff's <25% reject
conclusion the assumption that a PUT doesn't happen (in general)
out of the 'blue'.  Rather it happens in response to a previous
request which probably obtained the form which resulted in the PUT.

In general, it should be possible for the more mundane aspects of
authorization to be handled in conjunction with the previous
request. Thus, when the user is given a 'FORM' which will be 'PUT',
they have been pre-verified such that it is likely that the subsequent
PUT/POST will be acceptable.  Now the probability of rejection is 
much smaller as we are dealing with the probability that something
has changed such that the PUT would no longer be acceptable or some
specific characteristic of the PUT is not acceptable. We can't help
the changed status stituation but I would postulate that 'customers'
of that specific server will let their 'feet' do the talking if it
is a frequent problem.  I would also postulate that in this changed
status case, there will often be nothing the user/user agent can
do to fix the situation.

That leaves the question of pre-approval. If we presume that most
PUTs will be preceeded by a request that stages the PUT request, then
perhaps we could provide for 'pre-negotiation' via headers on the
staging response which deal with common reasons for ultimate
rejection.  Size and content type, language, etc. would seem well

Dave Morris

Received on Wednesday, 27 December 1995 17:16:25 UTC