- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 16 Dec 2014 22:36:16 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-12-16 22:31, Roy T. Fielding wrote: > 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). "OPTIONS uri" is fine, "OPTIONS *" is a problem... Best regards, Julian
Received on Tuesday, 16 December 2014 21:36:48 UTC