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

[Drake, Brian]

In fact, the EFF themselves seem to support the idea of handling redirects
that would have been handled just fine by the server:

<rule from="^http://([^@:/]+)\.wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary)\.org/w/index\.php\?title="
to="https://secure.wikimedia.org/wik$2/$1/wiki/"/>

They could have simply left this one up to the rule above:

<rule from="^http://([^@:/]+)\.wik(ipedia|inews|isource|ibooks|iquote|iversity|tionary)\.org/(w|wiki)/"
to="https://secure.wikimedia.org/wik$2/$1/$3/"/>

The really weird thing is that this isn’t even a redirect.
https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page is in fact an
internal redirect to
https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Main_Page – as
far as your browser is concerned, these are completely separate URLs that
happen to return identical pages. So redirecting to the more elegant URL
seems bad, both for HTTPS Everywhere and the Wikimedia servers.

On Wed, Dec 29, 2010 at 0524 (UTC-8), Drake, Brian <brian2 at drakefamily.tk>wrote:

> [snip]
> 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.
> [snip]
>
> 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).
>>
>> [snip]
>>
>> > 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.
>>
>> [snip] <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
> [snip]
> All content created by me Copyright © 2010 Brian Drake. All rights
> reserved.
>

--
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/14c3882a/attachment.html>