W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: Updated Prefer Header Draft

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 23 Oct 2012 13:07:08 +1100
Cc: "James M Snell" <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <98BBABCA-CDD1-49F5-B576-FCCFCB9E5A33@mnot.net>
To: "Adrien W. de Croy" <adrien@qbik.com>

On 23/10/2012, at 11:48 AM, Adrien W. de Croy <adrien@qbik.com> wrote:

> Hi James
> as a proxy developer, I'm always interested in how such protocol changes will impact my product, and there's always the cost/benefit analysis which on one hand looks at what is the likely implementation rate or importance of sites that may choose to rely on such an extension.
> So do you have any information (e.g. have there been any indications from implementors) as to who would be looking to implement such extensions?
> My only other comment on the draft would be that there are some implicit assumptions that may not always hold (but may be ok for the general cases), e.g.
> * you can't assume your header will make it to the server, so if the server relies on it, or the client relies on the server receiving it, there would need to be some clear way to indicate this so the client can know whether the server received the directive or not.  E.g. intermediaries that strip unknown headers.

I don't think this is a concern for Prefer -- after all, they're preferences, not requirements.

>  * you can't assume anything about how long it may take for a request to reach a server.  E.g. a PUT request going through a proxy that does AV scanning will take an unforeseeable period of time to receive, then scan the content before making an upstream request.  This could cause problems with the proposed "wait" preference.  In fact I struggle to see how "wait" would be used in practise, and the skeptical side of me wonders at its merit.

I share this concern, and I think I expressed it before.

Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 23 October 2012 02:07:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC