Re: Updated Prefer Header Draft

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.

* 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.

Regards

Adrien


------ Original Message ------
From: "James M Snell" <jasnell@gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 13/10/2012 7:09:54 a.m.
Subject: Updated Prefer Header Draft
>The last call on the Prefer draft has closed as of today. Based on the 
>excellent feedback I received during the last call, I have updated the 
>current draft and it has been handed off for IESG review. The current 
>draft is located here
http://www.ietf.org/id/draft-snell-http-prefer-15.txt
>
>The major changes based on feedback include:
>
>1. I have brought back the Preference-Applied response header. I know 
>that there are a few folks who feel this header is entirely 
>unnecessary but feedback I have received from a number of implementers 
>has convinced me it is. The use is optional and limited to cases where 
>the application of a preference may not be obvious and the application 
>of the preference could have an impact on the processing of a 
>response. 
>
>2. I have altered the definition of the wait preference slightly. 
>Essentially, it now specifies the clients assumption of how long 
>processing a request should take rather than indicating how long the 
>client is willing to wait for a response. The difference is subtle but 
>important, and the change is a very good one.
>
>3. I have made a number of editorial changes to the structure of the 
>document. Some section numbers have changed.
>
>- James