Re: -encryption draft -01

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).

>> 6.4. Confusion Regarding Request Scheme
>>
>>     ...
>>
>>     HTTP/1.1 MUST NOT be sent over HTTP/1.1 or earlier versions of the
>>     protocol.  Opportunistically secured HTTP requests MUST include an
>>     explicit scheme identifier.
>>
>> Doesn't compute.
>
> Whoa, I was in a hurry, but I didn't realize it was that bad.  That's
> awful.  Here's what the next version will say.
>
> "HTTP/1.1 MUST NOT be used for opportunistically secured requests."

OK, that parses now :-)

Best regards, Julian

Received on Tuesday, 16 December 2014 17:57:19 UTC