Returning a content location header does not require a redirect. You can return the negotiated content with the first response than still tell the client how it could have asked for that same content without negotiation. That's what the content location header means in the absence of a redirect status code.
Ralph
________________________________________
From: Code for Libraries <[log in to unmask]> on behalf of Joe Hourcle <[log in to unmask]>
Sent: Sunday, December 01, 2013 6:39 PM
To: [log in to unmask]
Subject: Re: The lie of the API
On Dec 1, 2013, at 3:51 PM, LeVan,Ralph wrote:
> I'm confused about the supposed distinction between content negotiation and explicit content request in a URL. The reason I'm confused is that the response to content negotiation is supposed to be a content location header with a URL that is guaranteed to return the negotiated content. In other words, there *must* be a form of the URL that bypasses content negotiation. If you can do content negotiation, then you should have a URL form that doesn't require content negotiation.
There are three types of content negotiation discussed in HTTP/1.1. The
one that most gets used is 'transparent negotiation' which results in
there being different content served under a single URL.
Transparent negotiation schemes do *not* redirect to a new URL to allow
the cache or browser to identify the specific content returned. (this
would require an extra round trip, as you'd have to send a Location:
header to redirect, then have the browser request the new page)
So that you don't screw up web proxies, you have to specify the 'Vary'
header to tell which parameters you consider significant so that it
knows what is or isn't cacheable. So if you might serve different
content based on the Accept and Accept-Encoding would return:
Vary: Accept, Accept-Encoding
(Including 'User Agent' is problematic because of some browsers
that pack in every module + the version in there, making there be so
many permutations that many proxies will refuse to cache it)
-Joe
(who has been managing web servers since HTTP/0.9, and gets
annoyed when I have to explain to our security folks each year
why I don't reject pre-HTTP/1.1 requests or follow the rest of
the CIS benchmark recommendations that cause our web services to
fail horribly)
