- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Wed, 07 Dec 2011 08:53:15 -0700
- To: Mark Nottingham <mnot@mnot.net>
- CC: James Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 12/06/2011 11:36 PM, Mark Nottingham wrote: > > On 07/12/2011, at 11:57 AM, James Snell wrote: > >> Current iterations based on today's feedback... >> >> http://www.ietf.org/id/draft-snell-http-prefer-06.txt >> >> Change summary: >> >> - replaced user-agent with client > > What's the reasoning here? Do you expect intermediaries to have preferences? IMO, the general reasoning should be "we do not want to exclude intermediaries without a specific reason because some of them might find the new mechanism useful". This is especially true when the mechanism can be extended. In this specific case, we have already come up with at least one possible use: wait=10 preference set by a proxy in a poorly connected environment when validating a cached response. See this thread for more info. >> - brought Preference-Applied back > This needs to be discussed. I'm very uneasy about turning this into > Yet Another HTTP Negotiation Mechanism. If there is an existing mechanism that can be reused to acknowledge which preference was honored, we should reuse it. Otherwise, a "yet another" acknowledgement mechanism seems justified. I am not an expert on this, but my understanding of the arguments presented so far is that reusing Content-Location to indicate whether the status preference was applied is not going to cover all possible use cases. I also find the Preference-Applied acknowledgement mechanism useful for debugging/troubleshooting. [ N.B. If "Preference-Applied" stays, please consider renaming it to "Preferred" to save a few bytes and to remove the implication that all preferences can be "applied" rather than honored, etc. ] Thank you, Alex.
Received on Wednesday, 7 December 2011 15:54:28 UTC