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

ACTION-741: concrete proposal on the use of the Via HTTP header comment

From: Francois Daoust <fd@w3.org>
Date: Thu, 24 Apr 2008 12:00:28 +0200
Message-ID: <48105A3C.8030006@w3.org>
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]

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: 

Open question
Should we have another property to say "I don't intend to transform" 
("passive" for instance)?

[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
[6] http://www.w3.org/TR/2007/WD-ct-landscape-20071025/#d0e227
[7] http://www.w3.org/2008/04/22-bpwg-minutes.html#item06

Received on Thursday, 24 April 2008 10:01:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:29 UTC