W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > April 2008

Issuing two requests, idempotency, comparison, etc (4.1.2)

From: Francois Daoust <fd@w3.org>
Date: Fri, 25 Apr 2008 14:17:35 +0200
Message-ID: <4811CBDF.5000000@w3.org>
To: public-bpwg-ct <public-bpwg-ct@w3.org>

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.
Received on Friday, 25 April 2008 12:18:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 April 2008 12:18:12 GMT