Re: Draft finding - "Transitioning the Web to HTTPS"

On 2015-02-17 13:11, Henry S. Thompson wrote:
> Eric J. Bowman wrote, back on 19 December [sorry for slow reply!]:
>
>> Henry S. Thompson wrote:
>>>
>>> Some non-anecdotal evidence, albeit still subject to varying
>>> interpretations, is available in a talk summarising my analysis of
>>> two sets of cache-logs, from June 2013 and June 2014:
>>>
>>>    http://www.ltg.ed.ac.uk/~ht/HST_noREST.pdf
>>>
>>> Start at slide 13 and stop after slide 15 if you're not interested in
>>> my critique of REST, but just want to see the numbers.
>>>
>> ...
>> Except the conneg stuff. Are you really saying nobody compresses HTTP
>> payloads on the wire? Because that's a real-world instance of conneg I
>> highly doubt nobody uses. Personally, I cache compressed content and
>> unzip it on the fly, to save CPU on the Celerons driving the budget
>> webhosting world, which finally got around to Vx and threading but still
>> aren't up to the task of ubiquitous HTTPS any more than the SPARC T1.
>>
>> What forms of conneg were you looking for, but apparently didn't find?
>
> The Squid logs which is what I was working with don't contain any
> request or response headers, just the response status code.  The only
> evidence available of what 2616 [1] calls "server-driven negotiation"
> and 7231 calls "proactive negotiation" is a 406 (Not Acceptable)
> response, indicating that the server has no representation satisfying
> the Accept... headers in a request.  I found only a handful of 406
> responses, none of which appeared to be actually responding to an
> attempt at conneg.  Note that this kind of conneg is what I think most
> people, including you, understand by "content negotiation" -- it's
> certainly what the TAG's _WebArch_ [3] and _Alternative
> Representations_ [4] are discussing.  Somewhat surprisingly (to me at
> least), it's also clearly recommended _against_ by 2616 and 7231.
>
> What they _recommend_ is what 2616 calls "agent-driven" [5] and 7231
> "reactive" [6] conneg.  This involves a server responding to a GET
> with a 300 Multiple Choices response, from which a user agent then
> selects, either automatically or by reference to a human.  Presence of
> 300 responses in the log would then constitute unequivocal evidence of
> "reactive" conneg.  But in fact what there is turns out to actually be
> evidence _against_ (conformant) conneg.  _All_ the examples in the log
> were generated by Apache's mod_speling [sic] module, offering "common
> basename", "character missing" or "mistyped character" hypotheses
> about failures to find a requested URI.
> ...

AFAIU, this is just a misunderstanding. I recommend reading the whole 
thread, in particular 
<https://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0531.html>.

Best regards, Julian