Hi Melinda, Thank you very much for the review. My responses below. 2017-07-05 4:37 GMT+09:00 Melinda Shore <melinda.shore@xxxxxxxxx>: > Reviewer: Melinda Shore > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Has minor issues. > > This draft defines a status code for sending an informational > response that contains header fields that are likely to be included in the > final response. A server can send the informational response containing > some of the header fields to help the client start making preparations > for processing the final response, and then run time-consuming operations > to generate the final response. The informational response can also be used by an > origin server to trigger HTTP/2 server push at a caching intermediary. > > Passed nit checker without complaints other than publication date. Sections > 5 and 6 should be appendices. The issue has been fixed in the github repo. > > One minor issue: in the security considerations section, "Therefore, > a server might refrain from sending Early Hints over HTTP/1.1 unless when > the client is known to handle informational responses correctly" is a bit squishy > (and contains a superfluous "when"). I'm not sure this merits a text change and > I'm rather certain that it doesn't merit normative 2119 language but it did stand > out as an overly soft recommendation. The superfluous "when" has been removed from the github repo. Regarding the wording, I think it would be better to keep the tone as-is, rather than suggesting implementers not to send an Early Hints response over HTTP/1.1 depending on the client. Users behind a proxy that cannot handle informational response correctly is exposed to response splitting attack regardless of if Early Hints is used (in HTTP/1.1, a server is allowed to send any informational response at it's own discretion). So while it is beneficial to warn the risks, I think that there is no merit in restricting the use of Early Hints. -- Kazuho Oku