- From: Eduardo Casais <casays@yahoo.com>
- Date: Mon, 24 Nov 2008 02:10:08 -0800 (PST)
- To: public-bpwg-ct@w3.org
> When the page that contains the HTTPS link is hosted
> by some other server, then there is no way to the
> targeted server to prevent the re-writing of the HTTPS
> links.
A similar problem occurs within the same WWW server, if
the following, quite common, configuration is in place:
1. A main WWW server providing standard desktop content, with e.g. the usual sections: information about the organization, services or products, press releases, open positions, guest book, documentation download area, etc, etc.
2. A sub-site, protected by SSL/TLS, for registered users. Users can enter into their account via a login page accessed through HTTPS.
3. A menu linking from the main site to the user accounts (such as "click here to login into your account").
Insofar as the main, public site is not restricted from any transformation (which makes some sense), the HTTPS URIs it embeds and that are pointing to the user account login page may be rewritten. We are facing the same issue as when an HTTPS link is rewritten on an "external" page such as results from a search engine.
There is currently no mechanism for a secure site or sub-site to state that HTTPS references to it in other, unknown, and possibly not yet existing pages, are not to be rewritten -- except by sticking to the convention that no HTTPS URI within a page or a redirect response is ever to be altered, and only allowing modifications of the secure link when end-users rely upon direct, opt-in access to the HTTPS URI (when entering the HTTPS URI manually into a transcoder home page).
E.Casais
Received on Monday, 24 November 2008 10:13:57 UTC