W3C home > Mailing lists > Public > public-bpwg-comments@w3.org > October to December 2009

Re: Re: Review of Content Transformation Guidelines Last Call? ( LC-2043 LC-2034 LC-2036 LC-2038 LC-2037 LC-2039 LC-2040 LC-2041 LC-2042)

From: <fd@w3.org>
Date: Tue, 06 Oct 2009 15:34:19 +0000
To: Mark Baker <distobj@acm.org>
Cc: public-bpwg-comments@w3.org
Message-Id: <E1MvC3P-00034z-Rz@wiggum.w3.org>

 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:

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


For the Mobile Web Best Practices Working Group,
Dominique Hazaël-Massieux
François Daoust
W3C Staff Contacts

 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:


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 Avoiding "Request Unacceptable" Responses:
> I don't understand the need for  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

The updated text is available at:


Your comment on Sequence of Requests:
> >From, "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:


Your comment on Original Headers:
> 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:


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:


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:

Received on Tuesday, 6 October 2009 15:49:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:51 UTC