Re: Review of Content Transformation Guidelines Last Call?

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.

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.

4.1.3 Treatment of Requesters that are not Web browsers

"Proxies must act as though a no-transform directive is present (see
4.1.2 no-transform directive in Request) unless they are able
positively to determine that the user agent is a Web browser"

That seems both vague and arbitrary.  What is a Web browser?  What's
the objective that this guideline is trying to meet?

Aside: the use of RFC 2119 keywords here seems quite out of place.
These are guidelines after all, no?  A "guideline" that uses "MUST" is
more like a protocol.

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)

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.

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.

>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?

4.1.5.5 defines a protocol.  This should be in an Internet Draft, not
in a guidelines document.

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?

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.

Mark.

Received on Tuesday, 5 August 2008 21:38:00 UTC