- From: David W. Morris <dwm@shell.portal.com>
- Date: Wed, 27 Dec 1995 17:11:43 -0800 (PST)
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 understood. Dave Morris
Received on Wednesday, 27 December 1995 17:16:25 UTC