- From: Thomas Roessler <tlr@w3.org>
- Date: Thu, 17 Jan 2008 19:12:45 +0100
- To: Ian Fette <ifette@google.com>
- Cc: public-wsc-wg@w3.org, tyler.close@hp.com
See ISSUE-181. Note that I'm not strongly invested into this particular idea; it just seemed logical that we say something about the deployment side *if* we propose a technique that's based on a certain assumption on deployments. -- Thomas Roessler, W3C <tlr@w3.org> On 2008-01-17 10:07:17 -0800, Ian Fette wrote: > From: Ian Fette <ifette@google.com> > To: public-wsc-wg@w3.org, tyler.close@hp.com > Date: Thu, 17 Jan 2008 10:07:17 -0800 > Subject: Re: ACTION-369: webarch implications of 7.2 > List-Id: <public-wsc-wg.w3.org> > X-Spam-Level: > Archived-At: <http://www.w3.org/mid/bbeaa26f0801171007u7dd5fd99u783a2ea4f344c7b8@mail.gmail.com> > X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 > > My worry is that it's often not possible (or very difficult) for someone to > keep http and https consistent. This includes people on shared servers, as > well as people with very complicated setups. For instance, > http://code.google.com takes you to Google Code, > https://code.google.comtakes you to normal Google search. Could this > be fixed? > Maybe/probably/who-knows, but is it worth the effort? Probably not, given > that we don't ever expect someone to try to access code.google.com via > https. > On Jan 17, 2008 10:03 AM, Thomas Roessler <tlr@w3.org> wrote: > > > > > Section 7.2 [1] was the object of recent discussions around > > ISSUE-123, noticing that the technique described in this section is > > not guaranteed to work. > > > > I propose to add the following note to an eventual rewrite of the > > section (which Tyler owes as ACTION-368): > > > > The technique outlined in this section is a best effort to > > steer the user toward a safer interaction. There is no > > guarantee that replacing the scheme in an "http" URI by > > "https" leads to a URI that references a resource in any way > > related to the original one. Also, when the current page > > was obtained through an unsafe HTTP interaction (such as > > POST), performing a GET request on a URI that was produced > > in this way might negatively affect session-based web > > applications. > > > > Tyler, can you just copy and paste this in (and possibly smoothen > > the language a bit) when you do ACTION-368? > > > > As a side remark, I wonder if there is an authoring best practice in > > here (for section 9) that suggests keeping http and https URI spaces > > consistent. Thoughts? > > > > 1. > > http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-must-have-tls > > > > -- > > Thomas Roessler, W3C <tlr@w3.org> > > > >
Received on Thursday, 17 January 2008 18:12:54 UTC