- From: Francois Daoust <fd@w3.org>
- Date: Thu, 24 Apr 2008 12:00:28 +0200
- To: public-bpwg-ct <public-bpwg-ct@w3.org>
[Note this action has a duplicate: ACTION-742 that I reference here for
tracker to pick the mail up]
Context
-------
As written in §4.1.3 [1] "Proxy Indication of its Presence to Server",
the "proxy MUST [...] include a Via HTTP header indicating its presence".
Via headers are described in the HTTP RFC2616, section 14.45 [2]. A
typical example of a Via header would be:
Via: 1.1 example.org [possible comments]
The hostname part merely states that the message went through a proxy,
but there's no way to distinguish between a "regular" proxy and a
CT-proxy. We agreed to use the comments part of the header and Aaron
suggested [3] we use a URI in the comment. This URI would typically link
to a POWDER resource describing the CT-proxy's capabilities. We'll most
probably go down the POWDER route, but with or without POWDER, as Bryan
pointed out during Seoul's F2F [4], a mere flag would be already a good
start to advertise the fact the message went through a CT-proxy.
The flag could be slightly completed to include the proxy's intention to
transform, although I'm not entirely sure we should pass on that
information to the server in the sense that even if the proxy doesn't
say "I intend to transform", it still may transform the response.
Use cases
---------
1. 3.d point in our list of requirements in §3.1 [5] is: "[the origin
server needs to be able to tell the CT-proxy] that it is unable or
unwilling to deal the request in its presence form". In the landscape
document [6], one of the requirements is "Origin servers and proxies
must be able to identify the actual identity of components of the
delivery context, including (other) proxies and browsers". I take both
requirements as meaning that the content provider must be able to tell
when there's a CT-proxy on the delivery chain, and be able to exercise
their right to refuse to serve a resource that they don't want to see
transformed by a CT-proxy. One may say the "no-transform" directive is
enough, but it's not exactly the same answer.
2. As mentioned by Andrew [7], knowing that a CT-proxy is on the
delivery chain is of much use for diagnostics reasons. If your content
was transformed before delivery, that's obviously something you'll want
to investigate. (There's a caveat: the difference between a regular
proxy and a CT-proxy is not so obvious, but I tend to think the
difference is large enough for the distinction to be worth while)
Proposed resolution
--------------------
If we go down the POWDER route, we'll need to define the vocabulary to
use to describe the CT-proxy's capabilities. The vocabulary will need to
be associated with a namespace URI. Basically, I suggest we already
define a property of this vocabulary that acts as a global flag. I'm not
an expert in vocabularies (feel free to educate me on this!), but I
guess we may simply use the namespace itself as the flag.
PROPOSED RESOLUTION: format of the VIA header comments: [a URI to a
POWDER resource that describes the CT-proxy's capabilities using the
vocabulary-to-be when we're ready to switch to POWDER or] the CT
namespace's URI "http://www.w3.org/2008/04/ct#". Intention to transform
must be indicated using the "active" property:
"http://www.w3.org/2008/04/ct#active".
Open question
-------------
Should we have another property to say "I don't intend to transform"
("passive" for instance)?
References
----------
[1]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080410#sec-proxy-presence-indication
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45
[3] http://www.w3.org/2008/02/26-bpwg-minutes.html#item05
[4] http://www.w3.org/2008/03/03-bpwg-minutes.html#item05
[5]
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080410#sec-requiremnts-summary
[6] http://www.w3.org/TR/2007/WD-ct-landscape-20071025/#d0e227
[7] http://www.w3.org/2008/04/22-bpwg-minutes.html#item06
François.
Received on Thursday, 24 April 2008 10:01:05 UTC