Storing language in session/cookie

[Mikołaj S.]

Hi,

I'd like to make a proposal of changing the way that current language is stored, at least, making this changeable by settings.

The problem is that even for non-logged users their language is stored in session (if it's supported or in the cookie otherwise).

That creates a session for every client, which makes serving static (ofc I mean static, but not media) content through an upstream

cache (such as Squid) really inefficient. I suppose selected language is not that secret to protect it by storing in session,

and cookie is just ok. For cookie-varying cache it's a huge difference.

I may be very wrong - in that case please just tell me what design concept lays behind this system. ;)

[Paul McMillan]

I'm not familiar with that subsystem, but if what you say is correct,
you should open a ticket. That sounds like a definite issue to me.

-Paul

[Mikołaj S.]

I know, but it just seems so obvious to me that I can't believe no one have ever encountered this problem before - I felt like I should ask ;)

[Łukasz Rekucki]

2011/3/4 Mikołaj S. <miko...@gmail.com>:

> I know, but it just seems so obvious to me that I can't believe no one have
> ever encountered this problem before - I felt like I should ask ;)
>

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Here are some tickets you might find interesting:

http://code.djangoproject.com/ticket/13217
http://code.djangoproject.com/ticket/12794
http://code.djangoproject.com/ticket/65

If you disable sessions, django will use a cookie to store the
language. If you have sessions enabled, then django checks the session
first which results in adding "Vary: Cookie" (even if it doesn't
contain any info).

I'm not an expert on caching, but even if you add a seperate cookie
for a language, but keep the sessions framework enabled, wouldn't that
still break caching ? After all the (session, language) cookie pair is
still unique and the "Vary" header doesn't let you name specific
cookies, AFAIK.

--
Łukasz Rekucki

[Mikołaj S.]

If I understand the middleware correctly, session cookie is created only when the session itself is modified, unless SESSION_SAVE_EVERY_REQUEST is True. So, after user language is set but before user authentication there could be only one, language cookie.

I think that http://code.djangoproject.com/ticket/13217 is the same problem but from the slightly different point of view. However it hasn't been solved,

the thread seems dead to me, but problem still exists.

[Mikołaj S.]

Sorry for bumping the thread, but could somebody familiar with session subsystem anwer it? It is critical for my work to know if this issue is my problem or Django's.

[Madis]

Well yes I think there is an issue here for sure. I think it would be
quite easy to solve this as follows - but I'm not sure if it's the
best approach.

There is a setting named LANGUAGE_COOKIE_NAME which never gets used if
you use session based cookies. The file cookie is just never saved.
But if there were an option to save data in the session and also save
the LANGUAGE_COOKIE as a file separately - then it would also persist
after logout and solve the issue with languages after the session gets
destroyed.

http://code.djangoproject.com/ticket/14825
I think this middleware fix only fixes things temporarily - and in the
long run you'd still want a persistent separate language cookie saved.


I would propose to have the set_language() view with options to set it
as a file based cookie or a session.
https://github.com/django/django/blob/master/django/views/i18n.py


It would allow the language file based cookie to have a very long
expire date and the session would still be usable for storing secure
data.

[Mikołaj S.]

I've created a ticket: http://code.djangoproject.com/ticket/15902

I agree with Madis. Having a setting to choose where the current language is stored would be convenient and also backwards compatible.

How do you think the setting should look like? I propose:

LANGUAGE_FORCE_COOKIE

...which defaults to False for backwards compatibility. And when it's True, the current language is also saved in a separate cookie, no matter if there is a session enabled.

But I also wonder if it won't be unnecessarily redundant to have the language stored both in a cookie and a session.

[Mikołaj S.]

As lukeplant commented on a ticket:

This is proposing the same thing as #12794, but for a different reason.

#13217 is related, but the solution proposed here was not proposed there, and doesn't have the same issues that caused the WONTFIX on that ticket. This change would help that problem if the cache is able to cache by language cookie.

I'm not in favour of yet another setting if we can avoid it - we need to know if there are any downsides to always storing in the cookie rather than the session. If not, we always store in the cookie. Since we've documented the current behaviour, we may however need a deprecation path involving a setting.

So it's now about whether to be backwards compatible but add another setting and complicate things a bit, or not to be backwards compatible and move current language to separate cookie permanently.

[Madis]

Well I think there is no need for another setting and I think there is
no problem setting the lang twice - as then the cookie is not always
accessed as it first checks for the language in the session. It only
looks for it in the cookie if there is no session or the customer is
returning to the site.
So the cookie for language just lives there and is only looked in if
there is no session available. It produces no overhead what so ever
because set_lang is only called when changing languages.

And if you want set_lang to store the cookie also then just configure
it in your urls.py - then we dont need another setting also. This can
be documented and maybe many people wont even need this - or want this
as their clients manly speak English. This would then also be
backwards compatible.

Well and the possible downside of this approach is that some people
dont want the language_cookie stored because they consider this
private data (for whatever reason there might be). So giving them an
option to set the cookie is or not is always good.

Right now I rewrote the set_lang view for my app so the cookie is also
stored and expires after 1 year - it works perfect after logout or
when revisiting the site.
http://dpaste.com/hold/535886/
Right now I have no options to set it or not because I want to use it.
But it would be very easy to write it optional with options to also
set the cookie and expiration time/date.

One thought is that maybe when revisiting and the session is also
available the middleware should write the language from the cookie to
the session again - so there is no additional call to look in the
cookie.

[Madis]

There is also a ticket here which proposes a patch -
http://code.djangoproject.com/ticket/14825
I used it last night - it also works but wont give the users the
freedom to choose if they want to set the lang cookie or not and also
adds overhead.

[Luke Plant]

On 26/04/11 14:21, Madis wrote:
> Well I think there is no need for another setting and I think there is
> no problem setting the lang twice - as then the cookie is not always
> accessed as it first checks for the language in the session. It only
> looks for it in the cookie if there is no session or the customer is
> returning to the site.
> So the cookie for language just lives there and is only looked in if
> there is no session available. It produces no overhead what so ever
> because set_lang is only called when changing languages.

This does not address the fact that accessing the session to check
causes a session to be created if it did not exist. This is what this
whole thread is about! See also the discussion on ticket #13217.

Luke

--
"I washed a sock. Then I put it in the dryer. When I took it out,
it was gone." (Steven Wright)

Luke Plant || http://lukeplant.me.uk/

[Madis]

Well we are actually not trying to address the issue on ticket #13217
I think. We are addressing the way language gets stored for the
client.
Because LocaleMiddleware checks for a session anyway. If it was
decided wontfix then doing it the way I supposed should be OK I think.

If I'm mistaken - please correct me.

[Mikołaj S.]

I don't see any good reason to store the language in session rather than cookie. And storing it in cookie has major advantage, that is avoiding creating unnnecessary sessions. I say if LocaleMiddleware is in our way to better behavior, let's just change it.

But I understand that revolution is not always a better idea than evolution, so Madis'es session-and-cookie storing is also an option for me, although I don't see how it could be useful.

If somebody has some arguments for session-based language storing, I'd see it gladly.

[Max Arnold]

Another approach is to store language in the url (useful for mobile handsets where disabled or unsupported cookies is still an issue).  Django app which uses this method: https://bitbucket.org/carljm/django-localeurl

[Mikoskay]

Yes, but obviously this is not going to be the blessed, default behavior.

--
Mikołaj Siedlarek

On Mon, Jun 27, 2011 at 3:15 PM, Max Arnold <lwa...@gmail.com> wrote:

Another approach is to store language in the url (useful for mobile handsets where disabled or unsupported cookies is still an issue).  Django app which uses this method: https://bitbucket.org/carljm/django-localeurl

--

You received this message because you are subscribed to the Google Groups "Django developers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/KD9VoA6u6sEJ.

[Vlastimil Zíma]

I just find out ticket #15902 while searching for completely different thing :)

I support storing language into cookie only (as final state) for reasons we encountered in our applications:

 - Language is not forgotten when user logs out / is logged out.
   - When this happens with languge in session, whole session is dumped including language and any further response is displayed with default language. This problem is described in #14825.

 - Language can be changed by GET request.
   - If language is stored in cookie, this avoids #3651 as cookies are only part of response and does not change state of session on server.

 - Language can be shared without necessity to share session
   - Language cookie can be not secure, thus shared between `https://` and `http://` URL even when session is secured. Also language cookie can be shared between subdomains without necesity to share session data e.g. `admin.example.com` and `www.example.com`. This would actually need a new setting LANGUAGE_COOKIE_DOMAIN.

We do not use cache that much yet, so we have not encouter problems with that.

I do not actually see any reason for not storing language into cookie. It generally does not contain any private data, your language preferences are usually in your HTTP headers anyway or in cookies from other webs you visited lately.

Parameters of language cookie could be LANGUAGE_COOKIE_NAME, LANGUAGE_COOKIE_DOMAIN, not HTTPONLY and not SECURE. Remaining are path and age. Path might be fixed to '/'. So only remaining is age. Given that cookie does not contain any private data, it can be hardcoded for 1 year (or other reasonable time).

I also like possibility to override language cookie params using kwargs on set_language view.