[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 13:34:22 UTC