Redirect traffic instead on forbidden

Feature Request Under Consideration
1

I don’t know if this is the right category as it’s not a feature of the system however I think that instead of returning a forbidden error when a user types www. infront of their custom link (ie www.example.quickfile.co.uk) it should redirect to the non-www version (ei example.quckfile.co.uk).

This doesn’t make a huge difference to the running of the system but it will improve useability of the site and as a web dev I’m picky about this things.

I would also like to take the chance to say I’ve used quickfile now to a few months and I absolutely love it. It makes managing my business so much easier.

Thanks @Glenn and all the team behind this great service.

2

Firstly, thank you for your positive words about QuickFile… it’s much appreciated!

The problem here is the wildcard SSL certificate we have would not cover multiple sub domains like this. We can’t redirect as your browser would intercept and block at the SSL resolution stage, the request would not even reach our server. The only way to achieve this would be to acquire an additional SSL certificate as follows, and this would need to be done for every single account we manage.

*.example.quickfile.co.uk

So regrettably it’s not something we can easily resolve. Although it would be interesting to know how often people prefix with www?

3

Hi Glenn,

No problem. Keep up the great work!

I know that not many people will prefix with www however it’s still a usability issue.

Since no data that needs to be encrypted (i.e. A login) will be sent till after the page has rendered can’t you first do the redirect from www to non-www then do the redirect to https.

Currently when user goes to www.exaple.quickfile.co.uk the browser throws SSL errors anyway.

Thanks,
Joel

4

Let’s say the user enters:

www.example.quickfile.co.uk

In this case we can actually reroute the request as you say (striping out the www). At the moment it’s mindlessly redirecting to SSL and then triggering the warning.

If a user enters:

https://www.example.quickfile.co.uk

We have no scope to redirect, as the browser will stop the request from being executed.

So definitely we can fix this first case and I will log this for review.

5

Hi Glenn,

I fully agree with the second scenario but if you get the first scenario impimented then it will add usability.

Maybe for the second scenario you could rerouted all traffic to non https then to non www then back to https.

A bit of a loop I know but it might work.

I don’t really understand how nginx works with htaccess and redirects so I apologise if it’s not possible to do all that in nginx!

Thanks,
Joel

6

If someone enters https://www.example.quickfile.co.uk, it’s impossible for us to do any rerouting as the browser will block the request. The other case is being looked at today.

7

Ah of course. The user will receive the error as soon as they connect before any rewriting rules.

I understand what you are saying now.

1 Like
8

Has anyone actually tried with multiple wildcards in the SAN e.g. *.*.quickfile.co.uk?
It seems opinion is divided about a) whether the SSL provider allows it and b) whether all/any broswer supports it.

9

On a DNS level it is possible.

Right now we have a wildcard DNS

*.quickfile.co.uk

Let’s say you wanted to handle www.example.quickfile.co.uk, you’d need either one of the following A records on your DNS:

*.example.quickfile.co.uk
www.example.quickfile.co.uk

In each case you have the first sub-domain hard coded (.example), so you’d need a record like this for every account on QuickFile. this is impractical as it means we need to apply DNS changes for every new QF account, resulting in 10s of thousands of A records.

Even if we handled the provision of A records I couldn’t say for certain of our SSL certificate would resolve.