RE: Content negotiation for request bodies

Adrien de Croy wrote:
> 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

The idea seems reasonable. It is basically implementing "Expect: 100-continue" in a way that has no side effects when the server doesn't understand it. But, you can't cram all the headers into a "Probe-Headers" header because of implementations that limit the size of headers. It would make more sense to have the headers included in the body, using a Content-Type that is a cross between message/http and message/external-body. 

Many servers/proxies are likely to reject PROBE even if they would accept the request it describes. So, there has to be a clear way of distinguishing between a failed PROBE, and a successful PROBE that indicates that the described request would fail.

The main problem is that, if the PROBE indicates that the described request would fail, then it still doesn't tell you what changes you would need to make to get it to succeed.

The more I look into this, the more I agree with Henrik Nordström when he said that it makes more sense to leave this kup to the application protocol than to encourage users to depend on 100-continue (especially due to the fact that 100-continue is so poorly implemented, as Julian pointed out). I no longer think it makes sense for the server to advocate the use of "Expect: 100-continue" for anything, really.

One thing I would like to avoid is stuff like "Accept-Patch" from the PATCH draft. This is a header that is returned in a response (usually OPTIONS) that lists content types that the server accepts in PATCH requests. Continuing with that leads to Accept-Post, Accept-Put, Accept-Encoding-Patch, Accept-Encoding-Put--basically N*M new headers, where N is the number of methods and M is the number of request/entity headers to use for negotiation. 

I do agree that Accept-Patch is definitely useful, but having it without an analogous mechanism for the fundemantal methods like POST and PUT doesn't make sense.

- Brian

Received on Wednesday, 27 February 2008 00:26:40 UTC