Some more reading :-(
Comments welcome!
Related editorial notes
-----------------------
Both editorial notes at the end of §4.1.2:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080410#sec-decision-to-transform
- 2 requests on the same resource
- 2 requests for the sake of comparison
Context
-------
In the most generic case where the proxy can't tell anything about the
server's preferences and capabilities, it should:
- issue the unaltered request and examine the response (see 4.4)
- if still in doubt, issue the altered request
1. 2 requests instead of one
----------------------------
For GET requests, issuing two requests should not be a problem, because
such requests are supposed to be idempotent, meaning that two identical
requests won't cause two separate operations, or possibly clearer
(though possibly less valid?) that the number of times you send the
request should not influence the response.
For POST (and PUT) requests, this is a problem, because such requests
are not supposed to be idempotent.
In practice:
- in the vast majority of cases, POST requests come after a GET request,
so the CT-proxy should already know what to do in that case.
- the idempotency of GET requests is sometimes not completely respected,
for example:
a) the origin server may increment a counter to compute statistics on
the access to a given resource
b) the origin server may use GET as POST
c) click-once confirmation URIs in emails can't use POST and use GET.
None of these cases are "valid" uses of GET requests (especially b!),
but then we can't fix all the problems of the Web with a CT guidelines
document, can we?
- even though the latency between the CT-proxy and the origin server is
not supposed to be poor, we should stick to the "Save the planet! Save
network bandwidth!" rule, so the less requests, the better!
I'd vote to emphasize both points in the guidelines and propose:
PROPOSED RESOLUTION 1.1: at the end of §4.1.2, add "The proxy MUST NOT
issue a POST/PUT request with altered headers when the response to the
unaltered POST/PUT request contains an HTTP status code 200"
(in other words, it may only send the altered request for a POST/PUT
request when the unaltered one was refused with a clear 406)
PROPOSED RESOLUTION 1.2.a: at the end of §4.1.2, add a "The theoretical
idempotency of GET requests is unfortunately not always respected in
practice. Not to break existing content, the proxy SHOULD strive to send
only one request whenever possible."
or
PROPOSED RESOLUTION 1.2.b: same as 1.2.a but in a note (and thus not
"SHOULD", but "should")
2. 2 requests for comparison
----------------------------
- the doc states, a few paragraphs before, that the proxy SHOULD NOT
alter HTTP requests unless the user's request would be rejected, so a
"well-behaved" proxy should not issue the altered request in other cases
anyway, and comparison should only take place when the proxy is in doubt
about the response being a "rejected" response.
- what do we mean by the examination of the response btw? Probably:
a) detection that the response is a "request rejected" one. That should
be the only case when the proxy respects the former statement. But let's
say it doesn't...
b) detection that the response contains CT directives such as
"no-transform"
c) detection that the response is already mobile-friendly
(content-types, link elements, Vary header)
Am I missing something?
The proxy may not be able to detect point a) for sure.
Point b) is easy to detect, but if it's "false", it shouldn't trigger
the proxy's decision to send the altered request ("not b)" means CT is
allowed or that the server is CT-unaware).
The same goes with point c) in the sense that "not c)" means the
CT-proxy thinks it received the desktop-oriented version of the page,
and thus why would the altered request be needed?
In short, the only examination that I can think of that makes sense for
the CT-proxy to state that it's "still in doubt" is the "request
rejected" one.
PROPOSED RESOLUTION 2.1: in §4.1.2, replace "Issue a request with
unaltered headers and examine the response (see 4.4 [...])" with "Issue
a request with unaltered headers and examine the response to check
whether it's a 'request rejected' one"
PROPOSED RESOLUTION 2.2.a: at the end of §4.1.2, add "Identifying HTTP
200 Status responses with a 'request rejected' message may be difficult.
The proxy MAY compare the responses to both the unaltered and altered
requests and select the most appropriate one to return to the user when
in doubt about the unaltered response, and only in that case."
or, if we adopt one of the proposed resolution 1.2.x
PROPOSED RESOLUTION 2.2.b: at the end of §4.1.2, complete "the proxy
SHOULD strive to send only one request whenever possible" with "In
particular, it SHOULD NOT issue duplicate requests for comparison
purpose as a generic rule."
My +1 go to:
1.1, 1.2.a, 2.1, and 2.2.b
François.