843357 - Evaluate dropping "www." from rev_host column

Status: NEW

(Toolkit :: Places, defect, P3)

Description

[Marco Bonardo [:mak]]

having in rev_host both the www and the non-www hosts causes troubles:
1. to us: we have queries far more complicated to group those in many cases, that are unreadable and less performant
2. to the users: for example in the history sidebar when grouped by site both www.domain.com and domain.com appear

The reason this happens is quite clear, per spec they may point to totally different content, but we started lots of time ago to ignore this fact, and the benefit is so small I feel like we could just do the last step and make them equal for history purposes.

The first thing to do here is to check if the change would break any assumption  or functionality in our code.

The patch should not be too hard, just a schema migration to rtrim "www." from rev_host

Comment 1

[Marco Bonardo [:mak]]

After a first look the critical points this would touch are:
- about:permissions. Most services already use the root domain, but some could be problematic. I must verify if the principal differs for the permission manager case, and cookies. More generally must be evaluated for each service, but eventually Places could store whether both www and non-www versions exist just for this purpose)
- forget about site.  This should be fine since most services already use the root domain and may end up being a win after all.
- history queries by domain.  This should not be problematic and would fix longstanding bug with having both www and non-www hosts in queries.

In the end looks promising, it should have e positive impact and in the first analysis I didn't find blockers, there may be some tricky bits in about:permissions but the perf and code simplicity wins look more prominent.

Comment 2

[Florian Bender]

The websites (couple of hundreds) of my university unfortunately do not work without the www prefix and do not redirect. 

This means that internally, websites have to be recognized with and without "www", whereas they are always displayed (in the various managers and panels) without "www" (and both "www" and sans-prefix versions have to be combined when there are two different occurences in the DB). 

Cookies are a tricky question. I'd prefer handling them differently for with/without prefix situations (i. e. send www-prefix cookies when visiting www.domain.tld or sub-sub-domains thereof only and not sending www-prefix cookies when visiting domain.tld), but the settings for "www" (e. g. in about:permissions) always apply to the root domain, too, because (user-) perceptually, there is no difference between the two variants (and admins do not provide different content on either variant). 

Optimally, the browser detects redirections from www to non-www domains and then updates the internal URLs (for cookies, history, etc.).

Comment 3

[Phoenix]

(In reply to Florian Bender from comment #2)
> The websites (couple of hundreds) of my university unfortunately do not work
> without the www prefix and do not redirect. 

Second that, it is usual case in corporate environment when global domain name used, unprefixed domain name points to domain controllers (DC) and prefixed one points to external (or DMZ) web site. Introduced change would break such setup forcing administering staff to create dummy redirect sites on DCs what increase attack surface and reduce security. Or remove Firefox as unusable in corporate browser.
Proposing wontfix this.

Comment 4

[Marco Bonardo [:mak]]

this bug is mostly technical and doesn't have the kind of downsides you are suggesting, the url doesn't change, the only thing that changes is the way we group pages in views for management (like removing visits or such).

(In reply to Florian Bender from comment #2)
> The websites (couple of hundreds) of my university unfortunately do not work
> without the www prefix and do not redirect. 

I hope your server administrators will figure that's quite bad for their users, regardless what we do.

> Cookies are a tricky question.

this has nothing to do with cookies, and would be wrong to consider cookies the same unless the cookie itself has a wildcard.

(In reply to Phoenix from comment #3)
> Second that, it is usual case in corporate environment when global domain
> name used, unprefixed domain name points to domain controllers (DC) and
> prefixed one points to external (or DMZ) web site.

As I said, this bug has no relation to the issue your are suggesting.

Comment 5

[Florian Bender]

(In reply to Marco Bonardo [:mak] from comment #4)
> this bug is mostly technical and doesn't have the kind of downsides you are
> suggesting, the url doesn't change, the only thing that changes is the way
> we group pages in views for management (like removing visits or such).
I was figuring that and totally support solving this Bug (e. g. about:permissions will also be cleaned up quite a bit by this change, IIUC). I was merely pointing out that there are some server configurations that should not be affected by this bug (as you said, they won't, by design) – however such a "feature" always needs to be crosschecked that it indeed does not affect peculiar configurations. 

> I hope your server administrators will figure that's quite bad for their
> users, regardless what we do.
I hope so, too, but I have my doubts. 

> this has nothing to do with cookies, and would be wrong to consider cookies
> the same unless the cookie itself has a wildcard.
So cookies are totally unaffected by this change? E. g. example.com, www.example.com and asdf.example.com will each have different cookie sets – and if so, how does a setting like disallowing cookies for www.example.com or example.com (depending on what get's displayed in about:permissions) affect other cookies from this domain?

Comment 6

[Marco Bonardo [:mak]]

yes, cookies are stored elsewhere.

Comment 7

[Marco Bonardo [:mak]]

This is something we should evaluate yet, when matching on domains rev_host helps a lot and this may speed up those matches.
We should also consider whether moz_origins should also be changed, though they have different scopes, so it's just something to evaluate.

This may also help grouping history by host, so we avoid having both a mozilla.org and a www.mozilla.org groups.