W3C home > Mailing lists > Public > www-tag@w3.org > February 2015

Re: connect

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 17 Feb 2015 13:21:11 -0800
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-Id: <3A607E69-097B-4CFE-822E-DB8E4620C1DF@gbiv.com>
To: Henry S. Thompson <ht@inf.ed.ac.uk>
On Feb 17, 2015, at 7:17 AM, Henry S. Thompson wrote:

> Julian Reschke writes:
> 
>> It might be a full representation of the identified resource,
>> *including* links to alternate versions. Think Wikipedia links to
>> alternate language versions.
> 
> Sure, but then it's not conneg at the protocol level, it's just people
> using the Web.  That was my point -- either not conformant, or not conneg.

I think you are trying to make an arbitrary point and selectively
reading the spec in order to support that point.  Looking at Squid
logs to support your conclusions is particularly absurd given
what is written in the spec.

The point that RFC7231 is making is that there are generally two
mechanisms for selecting content

  http://tools.ietf.org/html/rfc7231#section-3.4

In an attempt to help implementors remember them, I tried to come up
with names that distinguish the two by their primary characteristics.
Proactive negotiation for stuff the client tries to ask for in advance,
and reactive negotiation for stuff the client might want to know about
after the initial response.

Neither one is indicated by the status code.

The status codes are used to indicate what the user agent can do in the 
absence of a 200 response. Both 300 and 406 can be used in response to
proactive negotiation, though that would be considered very unusual and
tend to occur only with resources that are specifically intended to treat
negotiation as either a failure condition or a please-choose-yourself
requirement.  For the most part, such resources are only found in APIs
and intranet services, not on the wider Internet, and certainly not
something you would statistically encounter in a campus proxy.

The most common form of reactive negotiation are the links to various
language versions found on many home pages (usually on flag images).
Likewise, many sites now use a combination of javascript and locale
information within the user agent.  Your opinion about those not being
"part of HTTP" is simply irrelevant.  They are mechanisms for content
selection via HTTP and both are supported in the protocol, though not
completely within the core standard.  We have tried to do more of that
via header fields like URI, Alternates, and Link, but none of those
have been implemented consistently in browsers, so you won't
see them on general-purpose websites.

Finally, making generalized conclusions about all use of HTTP based on
only the internal traffic of a major University is the moral equivalent
of medical studies on teenage boys being extrapolated as the basis for
all human behavior.  Don't do that.

....Roy
Received on Tuesday, 17 February 2015 21:21:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 17 February 2015 21:21:36 UTC