Re: Content negotiation for request bodies

Just floating an idea.

GET has its good friend HEAD, which allows you to do the equivalent of a 
GET command without transferring any body.  In this case you can test 
for all sorts of things, including whether you will need to auth, 
whether the request might be accepted etc etc.

No other methods have such a helper method.

When discussing issues the other day, I came up with the concept of a 
potential new method that could address many of these issues.  For lack 
of a better name, I've called the method PROBE.

e.g.

PROBE someURI HTTP/1.1
Probe-Headers: Method=POST; Content-Length=1000000000; Content-Type="..."
... other headers that aren't being tested.
Content-Length:0


This defines a message with no body, but which can be used to test a 
request that the client really would like to make, but be able to make 
efficiently.

A server understanding PROBE could use the Probe-Headers fields to 
determine if and under what conditions, such a request would be 
processed (or not), and respond accordingly.  Any auth at a proxy or 
server could be set up in the realm of the POROBE command before the 
actual request was made on the same connection.  Therefore you can auth 
your way through any number of intermediaries before you need to 
transfer any request body, and check if the request will be allowed 
anyway, all without breaking any semantics.

HTTP proxies that pass unknown methods should already be able to forward 
this as well.

Adrien

Julian Reschke wrote:
>
> Brian Smith wrote:
>>> The problem with Expects, is it's only specified in HTTP 1.1, and 
>>> every link in the chain must support it for it to work.  In the 
>>> special case of
>>> Expects: 100-continue, this has grave problems with proxies that 
>>> I've raised before, and a heuristic timeout waiting for a 
>>> 100-continue which may never arrive causes further problems.
>>
>> There is a lot of software generating "Expect: 100-continue" now. In 
>> particular, the .NET client libraries seem to add this by default. 
>> Curl uses it by default. Apache supports it well. If there is any 
>> problem, it would seem to lie in with proxies. Is "Expect: 
>> 100-continue" really that problematic for commonly deployed proxies?
>> ...
>
> One problem is that server framework implementations (such as servlet 
> implementations) frequently answer with "100 Continue", without 
> actually doing what RCF2616 says they should do:
>
> "The purpose of the 100 (Continue) status (see Section 10.1.1) is to 
> allow a client that is sending a request message with a request body 
> to determine if the origin server is willing to accept the request 
> (based on the request headers) before the client sends the request 
> body. In some cases, it might either be inappropriate or highly 
> inefficient for the client to send the body if the server will reject 
> the message without looking at the body." -- 
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.2.3>
>
> Today servlet containers just say "100 Continue" without actually 
> consulting the servlet. That defeats part of what it's for.
>
> There have been proposals around for many years to improve this, but 
> as far as I know, nothing has happened so far.
>
> BR, Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 26 February 2008 23:15:46 UTC