- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 17 Feb 2015 13:21:11 -0800
- To: Henry S. Thompson <ht@inf.ed.ac.uk>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>
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