- From: Francois Daoust <fd@w3.org>
- Date: Mon, 16 Nov 2009 13:51:14 +0100
- To: Mark Baker <distobj@acm.org>
- CC: public-bpwg-comments@w3.org
Dear Mark Baker, The Last Call review period for the Guidelines for Web Content Transformation Proxies is over and we have not yet heard from you. We were wondering whether you had time to review the response to your comments below and the updated document, and whether you could let us know if you agree with it or not via email. The header of the previous email was generated from a template that did not give us the opportunity to apologize for the time it took us to get back to you. Comments received during the first Last Call review period generated a lot of discussions within the group. Resolutions of the issues took more time than expected. The group thinks the document has quite improved as a consequence, apologizes for the delay and would like to thank you again for your contribution! Thanks, For the Mobile Web Best Practices Working Group, Francois Daoust, W3C Staff Contact. fd@w3.org wrote: > Dear Mark Baker , > > The Mobile Web Best Practices Working Group has reviewed the comments you > sent [1] on the Last Call Working Draft [2] of the Content Transformation > Guidelines 1.0 published on 1 Aug 2008. Thank you for having taken the time > to review the document and to send us comments! > > The Working Group's response to your comment is included below, and has > been implemented in the new version of the document available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/. > > Please review it carefully and let us know by email at > public-bpwg-comments@w3.org if you agree with it or not before 6 November > 2009. In case of disagreement, you are requested to provide a specific > solution for or a path to a consensus with the Working Group. If such a > consensus cannot be achieved, you will be given the opportunity to raise a > formal objection which will then be reviewed by the Director during the > transition of this document to the next stage in the W3C Recommendation > Track. > > Thanks, > > For the Mobile Web Best Practices Working Group, > Dominique Hazaël-Massieux > François Daoust > W3C Staff Contacts > > 1. > http://www.w3.org/mid/e9dffd640808051437t1b40470au1675b44551cae5a3@mail.gmail.com > 2. http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/ > > > ===== > > Your comment on the document as a whole: >> Here's my comments. In summary, the group really needs to decide >> whether this is a guidelines document, or a protocol. It can't be >> both. A lot of work remains. > > > Working Group Resolution (LC-2043): > Thanks for your comment. We have tried hard in the new revision to make > sure that it is a guidelines document. > > ---- > > Your comment on 4.1.1 Applicable HTTP Methods: >> 4.1.1 Applicable HTTP Methods >> >> "Proxies should not intervene in methods other than GET, POST, HEAD and >> PUT." >> >> I can't think of any good reason for that. If a request using an >> extension method wants to avoid transformation, it can always include >> the no-transform directive. > > > Working Group Resolution (LC-2034): > This "should not" note shows the scope of Content Transformation as > discussed in the Guidelines Recommendation. It is not envisaged that a > content transformation proxy will intervene in a HTTP CONNECT for example. > Or that a content transformation proxy will transform anything in any > WebDAV methods. In fact we don't envisage any intervention in PUT either, > so we will drop this to clarify that the scope of the document is limited > to web browsing, using GET, POST & HEAD requests and their responses. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-applicable-HTTP-methods > > ---- > > Your comment on 4.1.5 Alteration of HTTP Header Values: >> 4.1.5 Alteration of HTTP Header Values >> >> RFC 2616 already says a lot about this. See sec 13.5.2 for example. >> >> "The theoretical idempotency of GET requests is not always respected >> by servers. In order, as far as possible, to avoid mis-operation of >> such content, proxies should avoid issuing duplicate requests and >> specifically should not issue duplicate requests for comparison >> purposes." >> >> First of all, do you mean "safe" or "idempotent"? That you refer only >> to GET suggests safety, but the second sentence suggests you are >> referring to idempotency. So please straighten that out. Oh, and >> there's nothing "theoretical" about GET's safety or idempotency; it's >> by definition, in fact. >> >> Secondly, if the server changes something important because it >> received a GET request, then that's its problem. Likewise, if it >> changes something non-idempotently because it received a PUT request, >> that's also something it has to deal with. In both cases though, the >> request itself is idempotent (and safe with GET), so I see no merit to >> that advice that you offer ... unless of course the problem you refer >> to is pervasive which clearly isn't the case. >> >> I also wonder if most of 4.1.5 shouldn't just defer to 2616. As is, >> large chunks of this section (as well as others) specify a protocol >> which is a subset of HTTP 1.1. (see also the RFC 2119 comment above) > > > Working Group Resolution (LC-2036): > Based on our experience and feedback from servers whose operators take > strong exception to the practice of repeating GETs, we think it is > reasonable to advise content transformation proxies operators of this > situation. We're not prohibiting reissuing requests, we're just observing > that content providers don't like it. > > ---- > > Your comment on 4.1.5 Alteration of HTTP Header Values: >> The rest of the 4.1.5.* sections all seem to be basically "Here's some >> things that some proxies do". By listing them, are you saying these >> are good and useful things, i.e. best practices? If so, perhaps that >> should be made explicit. > > > Working Group Resolution (LC-2038): > The document is not a set of best practices but a set of guidelines. > > ---- > > Your comment on 4.1.5.2 Avoiding "Request Unacceptable" Responses: >> I don't understand the need for 4.1.5.2. The second paragraph in >> particular seems overly specific, as proxies should obviously not be >> retrying POST requests unless an error - any error - was received. >> PUT messages can be retried because they're idempotent. > > > Working Group Resolution (LC-2037): > We agree and have removed all references to PUT. > We also agree that it should not be necessary to point out that proxies > should not be retrying POST requests, but also acknowledge that it has been > done in existing transformation deployments and think the emphasis is > needed. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-avoiding-request-unacceptable > > ---- > > Your comment on 4.1.5.4 Sequence of Requests: >> >From 4.1.5.4, "When requesting resources that form part of the >> representation of a resource (e.g. style sheets, images), proxies >> should make the request for such resources with the same headers as >> the request for the resource from which they are referenced.". Why? >> There may be lots of reasons for using different headers on these >> requests. For example, I'd expect the Accept header to be different >> for a stylesheet than for an image. What are you trying to accomplish >> with this restriction? > > > Working Group Resolution (LC-2039): > We agree and have clarified that we are only talking about keeping the > User-Agent HTTP header field consistent across requests. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-sequence-of-requests > > > > ---- > > Your comment on 4.1.5.5 Original Headers: >> 4.1.5.5 defines a protocol. This should be in an Internet Draft, not >> in a guidelines document. > > > Working Group Resolution (LC-2040): > We have requested provisional registration of the HTTP header fields > specified in this section with IANA: > http://www.iana.org/assignments/message-headers/prov-headers.html > > ---- > > Your comment on 4.2.2 Server Origination of Cache-Control: no-transform: >> 4.2.2 "Servers must include a Cache-Control: no-transform directive if >> one is received in the HTTP request." Why? What does the >> transformability of a request body have to do with the >> transformability of the associated response body? > > > Working Group Resolution (LC-2041): > We agree and have moved server behavior into an "Informative Guidance for > Origin Servers" non-normative appendix where we point out that servers > should consider including a Cache-Control: no-transform directive if one is > received as it may be an indication that the client does not wish to > receive a transformed response. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-cache-control-no-transform > > ---- > > Your comment on 4.3.2 Receipt of Warning: 214 Transformation Applied: >> 4.3.2 "If the response includes a Warning: 214 Transformation Applied >> HTTP header, proxies must not apply further transformation. " Why? >> The transformation indicated by the warning may have been the result >> of a server-side transformation which a client-side proxy may deem >> suboptimal, and so want to retransform. I see no problem with that. > > > Working Group Resolution (LC-2042): > We agree and have replaced the section with a guideline noting that > intermediate proxies may add a Cache-Control: no-transform directive if > they wish to inhibit further transformation by other proxies. > > The updated text is available at: > http://www.w3.org/TR/2009/WD-ct-guidelines-20091006/Overview.html#sec-proxy-use-of-no-transform > > ---- > > > >
Received on Monday, 16 November 2009 12:57:53 UTC