- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 16 Dec 2014 13:31:40 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Dec 16, 2014, at 9:56 AM, Julian Reschke wrote: > On 2014-12-16 18:46, Martin Thomson wrote: >> Feedback, structured or not, is always welcome. >> >> I didn't realize just how riddled this was with little bugs. >> >>> A client can also explicitly probe for an alternative service >>> advertisement by sending a request that bears little or no sensitive >>> information, such as one with the OPTIONS method. Likewise, clients >>> with existing alternative services information could make such a >>> request before they expire, in order minimize the delays that might >>> be incurred. >>> >>> Q: How is OPTIONS better than HEAD? >> >> I believe that either is fine. This is a f'rexample only. I think >> that we had a discussion where (and I'm going to rely on bad memory) >> Roy suggested OPTIONS over HEAD. OPTIONS * allows a client to learn >> things without perhaps revealing what resource it might be interested >> in. > > I don't think that doing a request for "/" will reveal more than a request for "*". > > Anyway, I'd like to avoid anything that might get people to think that "OPTIONS *" is anything but a bad design mistake. In particular I don't want any new specs to rely on it, when it's known to be hard to implement (as the asterisk form doesn't map to a proper URI). It isn't hard to implement. Please stop with the FUD. OPTIONS is preferred because it does not cause the server to do a retrieval (HEAD is usually implemented as an internal retrieval that gets truncated after the header fields, so it has almost as much cost on the backend as a GET). ....Roy
Received on Tuesday, 16 December 2014 21:32:07 UTC