RE: [ACTION-603] Conversation with Yves, our HTTP expert, about CT and Cache-Control extensions

> I'll get back to that in next CT call. Any comments?
Thanks for this Francois.

I'm dismayed at the thought of writing an RFC, and the time it would take for that to work its way through the system.

I wonder whether we do indeed want a Gateway? I'm wondering if this is merely a choice of words issue or whether there is a deeper significance? My view is that content should be transformed "more in sorrow than in anger", whereas saying it is a Gateway suggests that transformation is a matter of routine.

I can't say that I infer that the User Agent MUST NOT be changed from the referenced text. In the preceding section there is an explicit prohibition on changing the Server value. There is no such explicit prohibition noted wrt the User Agent.

Furthermore under no-transform
http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-01#section-15.2.5

      Therefore, if a message includes the no-transform directive, an
      intermediate cache or proxy MUST NOT change those headers that are
      listed in Section 6.2 as being subject to the no-transform
      directive.  This implies that the cache or proxy MUST NOT change
      any aspect of the entity-body that is specified by these headers,

The implication behind this is that a proxy MAY change other headers than those specified in 6.2 and that it is expected that proxies do change the value of headers.

I suppose all this is merely bandying with words and the long and short of it is that HTTP can often be interpreted as saying what you want it to say.

[also the referenced text is the draft replacement for RFC2616 - I guess to be forward looking we should reference it, but in that respect we do not have our feet very firmly on the ground]

I think we are going to have trouble identifying the type of representation that is required (handheld, etc) without a new header. Which is no doubt a problem.

I share Yves's view on rewriting HTTPS URIs however, that immediately knocks on the head the idea of mobile access to HTTP URIs that are not mobile friendly - and probably therefore a significant number of useful mobile services.

Jo
> -----Original Message-----
> From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Francois Daoust
> Sent: 01 February 2008 13:34
> To: public-bpwg-ct
> Subject: [ACTION-603] Conversation with Yves, our HTTP expert, about CT
> and Cache-Control extensions
> 
> 
> Hi,
> 
> This is a report of the discussions I had with Yves Lafon, our HTTP
> expert, about HTTP, content transformation, and the possible use of
> Cache-Control extensions.
> 
> In summary:
> 1/ there's no real "registration" process for Cache-Control extensions,
> and the way we should do it is to write an IETF draft and submit it to
> the HTTP working group for approval.
> 2/ we should be careful about wording. Our CT-proxy could be a
> CT-gateway.
> 3/ Yves frowns a lot at [@@allow-https-rewrite=yes] and [@@ User Agent
> Modified indication with the Original User-Agent indicated]
> 
> 
> I'll get back to that in next CT call. Any comments?
> 
> 
> More details:
> 
> 1/ Adding more HTTP headers would not receive any warm welcome, so
> Cache-Control extensions are indeed the most HTTP-friendly mechanism for
> our guidelines to control the proxy from the server's point of view.
> 
> Extensions are not registered anywhere. The best idea is to write an
> IETF draft such as the one Mark Nottingham wrote a year ago:
> http://www.mnot.net/drafts/draft-nottingham-http-stale-while-revalidate-
> 00.txt
> 
> Once written, the draft should be submitted to the HTTPBis working group
> for comments and approval. This of course raises questions such as:
> - who would edit this draft?
> - how long would it take for the draft to be looked upon and validated
> by the HTTPBis working group? FYI, the above example has not been
> presented to the working group yet, and Mark is the Chair of the working
> group. This doesn't mean it can't be done, it probably just isn't one of
> his priorities, but still...
> 
> 
> 
> 2/ Although it's only indirectly stated in the HTTP RFC, a proxy MUST
> NOT change the User-Agent header or rather it MAY complete the
> User-Agent header but MUST NOT override it.
> 
> The reference to that lies with the definition of the User-Agent header
> and the "originating" term:
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-01#section-10.9
>       "The User-Agent request-header field contains information about
> the user agent originating the request"
> 
> The solution is in wording. If the guidelines are to say that the
> CT-proxy MAY change the User-Agent header, then we'd better call it a
> CT-gateway. See terminology:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-01#section-1.3
>       "Unlike a proxy, a gateway receives requests as if it were the
> origin server for the requested resource"
> 
> Unlike a proxy that passes requests on, a gateway re-issues the HTTP
> request and is thus allowed to set HTTP headers to whatever it wants.
> 
> 
> 
> 3/ Getting to the proposed features there are two features that made
> Yves look at me rather suspiciously:
> 
> a) the first is the [@@allow-https-rewrite=yes] feature.
> 
> [I had raised the subject during last call and Andrew agreed to write a
> note about it:
> http://www.w3.org/2008/01/29-bpwg-minutes.html#action02 (ACTION-633)]
> 
> Even if the guidelines impose to request the user's approval before
> re-writing HTTPS links, even though data would still be encrypted from
> the client to the CT-proxy and from the CT-proxy to the server, this
> means that we could get into following situation:
> 	- the end-user says "OK, rewrite HTTPS links"
> 	- he accesses his bank's site
> 	- he enters his credentials in a rewritten form.
> When that happens, it means the CT-proxy knows the end-user's
> credentials.
> 
> If that's the case, it poses a serious security threat. There must not
> be any single case where the end-user's banking credentials may be known
> by someone else, even with the agreement of the end-user, no matter how
> terms and conditions are written. I second Yves on that. Am I missing
> something?
> 
> b) the second is the [@@ User Agent Modified indication with the
> Original User-Agent indicated] feature.
> Modifying the User-Agent (provided wording is appropriate) is not that
> problematic. To indicate the original User-Agent in another HTTP header
> (or at another position in the User-Agent header) is really not in the
> "spirit" of HTTP.
> What should be done in that case is:
> 	1. the Proxy sets the User-Agent to whatever it wants
> 	2. if the server wants to serve a user-agent specific, it returns a
> Vary: User-Agent header
> 	3. the Proxy re-runs the HTTP request with the original user-agent.
> I understand there may be cases when knowing the original User-Agent
> really is needed though. I'll include the topic in next CT agenda.
> 
> 
> François.
>

Received on Friday, 1 February 2008 14:36:04 UTC