[HTTPS-Everywhere] Adding or removing of “www.”

[Drake, Brian]

I have found that both explanations can be true, depending on which site
you’re looking at. Considering the first example, on some sites,
https://www.domain/ redirects to https://domain/ anyway; on some sites, it
returns a certificate error.

Still considering the first example, I’m not saying that HTTPS Everywhere
needs to intercept requests to https://www.domain/ and redirect them to
https://domain/, but that it would often be beneficial. At worst, it would
speed things up a little (assuming the server would have returned a redirect
anyway); at best, it would prevent a cert error.

Yes, HTTPS Everywhere does intercept HTTPS requests, as it should, for the
reasons outlined above. I assume that add-ons hook into all requests the
same way (regardless of scheme), so it’s actually easier for HTTPS
Everywhere to just apply some regex to all requests. In fact, the built-in
Facebook rule implements my suggestion (albeit with more obscure domains),
presumably to avoid cert errors. (I also use it for a slightly different
purpose: redirecting www.facebook.com and login.facebook.com to
ssl.facebook.com, as a subtle way of encouraging the use of EV (Extended
Validation) certificates.)

On Wed, Dec 29, 2010 at 0322 (UTC-8),
<https-everywhere at lists.grepular.com>wrote:

> On 28/12/2010 2234 (UTC-8), Drake, Brian wrote:
>
> > Rules are often of the form:
> >
> > <rule from="^http://(www\.)?domain/" to="https://domain/"/>
> >
> > or
> >
> > <rule from="^http://(www\.)?domain/" to="https://www.domain/"/>
> >
> > Not only do these rules redirect to HTTPS, they potentially change the
> > rest of the address too. Presumably that’s because https://www.domain/
> > would ultimately redirect to https://domain/ anyway (for the first form)
> > or https://domain/ would ultimately redirect to https://www.domain/
> > anyway (for the second form).
>
> I assumed that most of the rules do this because the SSL cert is only
> valid for "domain" or "www.domain", not both. That's certainly why I've
> been writing rulesets of that format.
>
> > In that case, why not change “http” to “https?” in the “from” values to
> > save a request to the server when https://domain/ (for the first form)
> > or https://www.domain/ (for the second form) is requested? The benefit
> > would far outweight the cost, I think.
>
> I don't really understand what you're saying here. In the first examples
> you provided if you go to one of:
>
> http://www.domain/
> http://domain/
>
> HTTPS-Everywhere redirects you to:
>
> https://domain/
>
> Are you suggesting that if somebody goes to https://www.domain/ it
> should also handle redirecting to https://domain/ rather than leaving
> the server to do it? I'm not sure if the code even looks at https
> requests? I can't see a reason why it would need to.
>
> --
> Mike Cardwell [snip]
>

--
Brian Drake

Alternate (slightly less secure) e-mail: brian at drakefamily.tk
Alternate (old) e-mail: brianriab at gmail.com

Facebook profile: Profile ID
100001669405117<https://ssl.facebook.com/profile.php?id=100001669405117>
Twitter username: BrianJDrake <https://twitter.com/BrianJDrake>
Wikimedia project username:
Brianjd<https://secure.wikimedia.org/wikipedia/meta/wiki/User:Brianjd>(been
inactive for a while)

All content created by me Copyright © 2010 Brian Drake. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101229/4f1749db/attachment.html>