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

Henry S. Thompson wrote:
> 
> 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.
>

Because in practice, there's no reason a client wouldn't allow a server
defaulting to e.g. text/plain, to respond 200. Therefore, 406 responses
are rare, and typically result from a request for one-and-only-one
format. Which, you're right, isn't an attempt at conneg -- it's a
measure of I-don't-know-what even when I could see the headers in my
server logs, for both servers -- one conneg, one not, statistical blip
either way.

>
> 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 I understand about conneg is a matter of public record on rest-
discuss, backed up for several years by working code showing off some
nifty conneg-with-caching tricks, including the use of stateless
cookies, personalized/privatized content with caching using HTTP Auth,
etc. One of the big "aha" moments with REST, is understanding Roy's last
paragraph, here (or anywhere else similar statements may appear):

https://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0286.html

When for so many of us, learning REST got sidetracked into using server
conneg and one-off media types which were always more implementation
artifacts, than the desired architectural style. Mo' bettah if the
Taylor, et. al. "Software Architecture" textbook had come along sooner,
which discusses late binding of representation to resource, without
getting any deeper into protocol matters than stating "The particular
form of the representation can be negotiated between REST components."

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

Right. All the tools are there, just no browser implementation, and
lack of same is all you're measuring. There's more than one way to skin
this cat, but many a Web developer has wondered if there shouldn't be
some 300 tie-in with browser chrome, i.e. user-configured preferences.

REST developers have made interesting use of this protocol mechanism
off the Web. My 300 responses are XForms-driven, human interaction is
possible and the result may be "stickied" in the client, but I use the
round-trip to perform XSLT and Javascript "feature detection" to make
those choices automatically.

Which is really no different than an awful lot of "reactive" conneg in
the wild, where a script might insert a link to some CSS or any number
of other tricks. I'm a REST guy, so for the sake of keeping my protocol
traffic self-descriptive, I'd much rather do this sort of thing in 300
responses than 200 responses. It also allows human override, the same
way for any website from a publisher POV even if implementations vary.

What I'd like, is other possible variants to appear in a drop-down menu
list (or whatever). Like if a PDF is available, and a plugin exists for
it, but HTML was selected. There's no telling what interesting uses
folks would find, if we had some competing implementations to try.

I can't help but think this is overdue nowadays. I don't know of any
way to measure it, but I would label "reactive conneg" everything Web
developers are doing to determine just what sort of device and screen
real-estate they're dealing with, agree that there's an inherent one-
round-trip penalty somewhere because of it regardless, and put that
traffic under its own response code for visibility.

This is a point of architecture that I'd like to see the TAG advocate.

>
> In conclusion, there is concrete evidence the servers do _not_
> implement what the RFCs recommend, and indirect evidence that there's
> very little of what I at least _thought_ was the kind of conneg
> clients and servers _did_ use.
> 

There used to be more proactive conneg, but that fell out of style as
user-agents proliferated with the rise of the smartphone and then the
tablet, in conjunction with the increasing popularity of Javascript
libraries including feature detection. It would be untenable to use
proactive conneg to sort user-agents nowadays, but why would anyone
still want to?

I see reactive conneg everywhere I look, but think it's just as bad
architecturally as serving "fail whale" pages as 200. If 300 were
implemented in browsers, I'd call both protocol abuse.

>
> To be clear and careful, if I understand you correctly you might be
> right -- there might be a huge amount of traffic consisting of
> "Accept-Encoding: gzip" requests from clients and gzip-encoded
> responses from servers -- such successes will not be detectable as
> such in the logs.
>

Any more than I can detect conneg in my own server logs, unless I set
the flag I made for logging just that.

-Eric

Received on Wednesday, 18 February 2015 22:22:53 UTC