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

On Fri, 2008-02-01 at 14:35 +0000, Jo Rabin wrote:
> > 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 am as well, especially for the second part (the draft should not be
long and we already have a template...)


> 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.

Actually, I view it more like saying "beware, CT ain't no routine!": if
you do transformation, you are indeed being aggressive, and as such,
you're not merely a (non-transparent) proxy anymore. Where "not merely a
proxy anymore" is "a gateway". That may be too HTTP-centric though and
we may decide to shrug at it and keep on using the term proxy...

> 
> 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.
[...]

It isn't written anywhere for sure. That's where the "spirit" of HTTP
comes in... We may want to ask other HTTP folks about it to check
whether they all agree on the matter, but I think Yves' view fairly
represents theirs. The header is not included in the list of headers
that MUST NOT change, in part because it MAY change (such as the
Openwave gateway that added (still does?) a UP.Link/x.y part to the
User-Agent). But the definition of the User-Agent makes it clear it must
contain something that identifies the user agent making the request. If
we do define our proxy as a gateway though, the violation of the
"spirit" disappears, as from the server, the gateway would be viewed as
the user agent making the request.

Again, that may be playing with words, but I guess my point is we should
be consistent with the HTTP RFC since it's the base of our guidelines.


> 
> [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]

My bad, I referenced this text because the division into different pages
makes it easier to read, but these extracts have not changed the
slightest from those of RFC2616.


> 
> 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.

It is.

This would be a cool application of the experimental RFC 2295 you
mention in the draft (on automatic content negotiation), but it's
definitely too experimental to be quoted.

Between the proxy and the client, this could be done with the same kind
of magic mentioned to let the client in control of the proxy: web-based
interface, user's preferences, ...

Between the server and the proxy, that's trickier. Requiring all servers
to use a DDR to identify mobile users when they only have a desktop and
a mobile version would not be very useful.

Maybe we could propose that they actually use a DDR to identify desktops
and serve the handheld version by default? (So what, isn't Mobile Web
supposed to rule over the Web?)

I propose we talk about it in next call.


> 
> 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.

I understand it limits the possibilities in terms of useful mobile
services, and I also understand it's already being done by some content
transformation proxies. But the banking example is one that will be
difficult to put aside when we try to convince external non-mobile
people that this is amazingly needed.


> 
> 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 16:36:36 UTC