Re: HTTPS rewriting vs Origin

Thanks Thomas!

I'm trying to get a precise view of things that may break here. See 
comments inline.


Thomas Roessler wrote:
> 
> Rewriting of HTTPS URIs implies that the origin of web applications is 
> changed.

Content Transformation for Web applications is more than likely to break 
things in any case.

It is not explicitely forbidden in the guidelines because there is no 
way to define standard Web browsing (whatever this may mean). The latest 
draft of the guidelines says:

[[ Before altering aspects of an HTTP request proxies need to take 
account of the fact that HTTP is used as a transport mechanism for many 
applications other than "Traditional Browsing". Alteration of HTTP 
requests for those applications can cause serious mis-operation. ]]

 
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/081107#sec-non-web-browsers


> This is likely to break a number of things:
> 
> - access to cookies
> - web applications that rely on the same origin policy
> - access to any functionality that keys off the origin

Is it specific to HTTPS though?
I mean, the same thing may occur if a CT-proxy rewrites a normal HTTP 
link and artificially change the origin, right?
I'm not trying to dismiss the comment here, simply trying to understand 
what it encompasses and where it may fit.


> The breakage will come in several flavors:
> 
> - the application's actual origin will be distinct from the one expected 
> by code within the application

Understood. Same as above, I don't think that's specific to HTTPS.


> - origins that are expected to be distinct may be mapped to the same string

I'm not sure I really understand the problem here.
What is the difference between that situation and, say, two users on the 
same computer connecting to the same Web site using HTTPS? From the 
point of view of the server, there ought to be two origins in this case, 
right?

Could there be a case where the server replies to someone with the data 
of someone else? If so, is there anything the proxy may do to prevent 
that from happening and that we could recommend? (e.g. proxies MUST NOT 
re-use TLS connections for different clients, or something similar that 
actually means something?)


> - the application's origin when ran through a content transformation 
> proxy will be distinct from the origin when ran without the proxy, 
> breaking persistent stores on the client-side.

Understood as well, and equally triggered by the change of origin, so 
not specific to HTTPS.


Francois.


> 
> At the very least, the specification should discuss the implications 
> HTTPS link rewriting.
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>

Received on Friday, 14 November 2008 16:29:48 UTC