add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

Hi

I've created a ticket to propose adding a preferred/default protocol in the "sites" framework at https://code.djangoproject.com/ticket/26079

tim suggested I bring this to the mailing list and said the following:

I'm not immediately convinced that a database field is the way to go for a couple reasons:

1. It would make data less portable between development (where SSL is often not in use) and production.
2. I'm not sure it's a common case that only some sites would use SSL but not others.

A third-party library called django-hosts, which djangoproject.com uses, adds a setting called ​HOSTS_SCHEME to solve this. I think there's been some discussion about merging at least parts of this library into core since it solves common problems.

See also #10944 (we might close this ticket as a duplicate of that one) and #23829 (about customizing ping_google to allow https). I think the best course of action would be to consider this feedback and write to the DevelopersMailingList with your proposal. Either solution of a new setting or a new database field need feedback from a wider audience. Thanks!

• actually I would say it is even more portable as you would probably use different databases between dev and prod , meaning you can have http in dev but https in prod
  
• its not just for SSL but also maybe a it could be used with other protocols/schemes such as dav, webcal, feed
  
• third party libraries could now have a definitive way of generating a full URL 

what do you guys think?

[Eric Rouleau]

since no feedback has been given yet,   I will add that the change is just an addition (new feature)  meaning there is no breaking of code , it just provides a way to define a default protocol for a given SITE, and will ultimately default to http when none is specified

[Daniel Chimeno]

Hi,

I think the same in the case of:

1. It would make data less portable between development (where SSL is often not in use) and production.

So maybe  a settings option could work.

[Eric Rouleau]

1. it's not necessarily about SSL, it can be for any protocol but SITE dependent.
   
2. and for the dev/prod , your data will be different anyway so you put the preferred protocol accordingly to your setup.
   
3. it's only for generating full URLs, not for internal links (ex: sitemaps). 

a settings option could work too for sure, but I think we have more flexibility with the sites framework, and any time you need the protocol it's to generate a full URL which also needs the domain name.

[Tim Graham]

I believe it's a common use case to import a copy of a production database and examine it locally -- that's what I meant about portability.

I'm not aware of any Django usage that involves serving protocols other than http(s). Is this a case you've come across?

[Aymeric Augustin]

On 25 janv. 2016, at 14:19, Tim Graham <timog...@gmail.com> wrote:

I believe it's a common use case to import a copy of a production database and examine it locally -- that's what I meant about portability.

I’m not convinced by this argument because the data for the Site model will be wrong anyway in this situation. Or did I miss something?

-- 

Aymeric.

[Tim Graham]

Oh, looks like django-hosts also has this problem. It looks like in some cases the URLs will be correct (due to the PARENT_HOST setting, I think, which is 'djangoproject.dev:8000' in the djangoproject.com dev settings), but if you are browsing a different host (e.g. the docs site), then those URLs use the value from the Site model.

Another thought: I've sometimes thought that the Site model violates the principle that you shouldn't put configuration in your database. I guess there's some usefulness to having a ForeignKey to the site, but... would it be feasible to offer a SITES setting that could be used instead? e.g.

SITES = {
    1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
    ...
}

That would solve the portability issue, I think, since you could easily override the necessary parts in development settings. Not sure if it'd be palatable to deprecation the models though. I don't think maintaining both versions would be worthwhile in the long run.

[Carl Meyer]

On 01/25/2016 09:01 AM, Tim Graham wrote:
> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev
> settings), but if you are browsing a different host (e.g. the docs
> site), then those URLs use the value from the Site model.
>
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would
> it be feasible to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd
> be palatable to deprecation the models though. I don't think maintaining
> both versions would be worthwhile in the long run.

+1 to this, I've long felt that the Site model was an anti-pattern. I
don't know if it's worth deprecating and switching to a different
system, though; it'd be a relatively painful deprecation for those using
it, I would guess.

Carl

[James Addison]

In using Marten Kenbeek's URL dispatch rewrite branch, I've found that using the pattern of defining some site configuration in your settings is the way to go: it more easily allows you to have URL patterns on multiple domain/scheme combinations.

I use a dict similar to what Tim has shown, and then use it to initialize my scheme/domain URL constraints in my root urls.py.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.