Django detects HTTP Accept-Language header in case-sensitive manner

[Wayne Ye]

I noticed on small defect here while I was testing my django website's 
I18N/L10n, basically below are example Accept-Language headers sent by 
Chrome and Firefox (all latest version):

Chrome: Accept-Language:  *zh-TW*,zh;q=0.8,en-US;q=0.6,en;q=0.4
Firefox:  Accept-Language:  *zh-tw*,zh;q=0.8,en-us;q=0.5,en;q=0.3

You noticed that "*zh-TW*" and "*zh-tw*", according to the standard: w3c 
and ietf 
rfc2616 , the language tag(s) 
are lower-cased.

But I've verified that Django will only correctly recognize Chrome's 
request (i.e. treat end user prefers zh-tw), for Firefox example above, 
Django will actually fallback to en-us/en.

Could some fellow developers in this forum kindly triage this issue? Once 
confirmed I will create a ticket in Trac and submit a pull request 
accordingly, expecting any feedback on this.


Thank you and best wishes!


--
Everything is worth doing is worth doing well!
Wayne's Geek Life http://WayneYe.com 
Infinite Passion On Programming!

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72d66b8d-2286-4a81-8738-871e6944c722%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration challenges

[Erik Ashepa]

Hi, 
I've presented the third feature in the user group.

I'll try to clarify what I've meant.

A destructive operation is any operation which would break backward 
compatibility with a previous version of the application.
I proposed implementing the ability to have  multiple south  migration 
sequences mapped to multiple south tables in the database.
And having the ability to indicate to which migration sequence I'm adding the 
migration via the cli
for example two migration sequences :
1. Additive: new tables, columns
2. Destructive: delete tables, columns , migrate data to new scheme.

This feature could also be of value when migrating a model between diango apps.

Erik.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1af61e31-7a77-45e4-9a99-fd7e990fa28f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration challenges

[Marc Tamlyn]

Adding a not null column can be a breaking operation
On 26 Sep 2014 13:29, "Erik Ashepa"  wrote:

> Hi,
> I've presented the third feature in the user group.
>
> I'll try to clarify what I've meant.
>
> A destructive operation is any operation which would break backward
> compatibility with a previous version of the application.
> I proposed implementing the ability to have  multiple south  migration
> sequences mapped to multiple south tables in the database.
> And having the ability to indicate to which migration sequence I'm adding
> the migration via the cli
> for example two migration sequences :
> 1. Additive: new tables, columns
> 2. Destructive: delete tables, columns , migrate data to new scheme.
>
> This feature could also be of value when migrating a model between diango
> apps.
>
> Erik.
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1af61e31-7a77-45e4-9a99-fd7e990fa28f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ENowjxK0pb15EnCcWX6LFB%2B572cob8vF%2BwBdyQvsQwiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django detects HTTP Accept-Language header in case-sensitive manner

[Carl Meyer]

Hello Wayne,

On 09/26/2014 01:58 AM, Wayne Ye wrote:
> I noticed on small defect here while I was testing my django website's
> I18N/L10n, basically below are example Accept-Language headers sent by
> Chrome and Firefox (all latest version):
> 
> Chrome: Accept-Language:  *zh-TW*,zh;q=0.8,en-US;q=0.6,en;q=0.4
> Firefox:  Accept-Language:  *zh-tw*,zh;q=0.8,en-us;q=0.5,en;q=0.3
> 
> You noticed that "*zh-TW*" and "*zh-tw*", according to the standard: w3c
> and ietf
> rfc2616 , the language
> tag(s) are lower-cased.
> 
> But I've verified that Django will only correctly recognize Chrome's
> request (i.e. treat end user prefers zh-tw), for Firefox example above,
> Django will actually fallback to en-us/en.
> 
> Could some fellow developers in this forum kindly triage this issue?
> Once confirmed I will create a ticket in Trac and submit a pull request
> accordingly, expecting any feedback on this.

Here's the section of RFC 2616 that makes it explicit that language tags
should be treated as case insensitive:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.10

I haven't tested, but based on code inspection of
translation.get_language_from_request() and the functions it calls, it
appears to me that you are correct; Django is incorrectly handling
language tags as case-sensitive. If you'd be willing to file a bug and
submit a pull request, that would be great.

Ideally (ISTM) the pull request would be comprehensive in testing and
implementing case-insensitive locale-name handling throughout: i.e. not
just in handling the HTTP header, but also checking against
settings.LANGUAGES, etc.

I wonder if this also has implications for checking whether a given
locale is present on the system. It looks to me like we also do this
case-sensitively right now, but we should do it case-insensitively. This
might be a bit of work, since it would mean that rather than just
checking for the existence of a particular locale directory as we do
now, we would need to read in all the available locale names into memory
(presuming we can't/don't want to enforce that all locales on disk are
lower-cased or whatever).

(I'm not the most i18n-experienced member of the core team by far, so
hopefully if I'm totally off-track here someone will weigh in to correct
me.)

Carl

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54258718.1090304%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

some suggested code change in Django 1.6.7

[Arun Marathe]

This is not a feature request per se, but it is not exactly a bug report 
either.

 

We are recently upgrading from Django 1.5 to Django 1.6.7. One other 
relevant package version of interest is psycopg2 which is at 2.5.4.

 

After upgrade, many test cases were failing with the classic 
"InterfaceError: connection already closed" originating from psycopg2. Here 
is a typical stack trace in which user-name and app-name have been obscured.

 

 

  File "/home/user1/sme-appname/src/session_csrf/__init__.py", line 68, in 
process_view

token = cache.get(PREFIX + key, '')

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/core/cache/backends/db.py",
 
line 61, in get

cursor = connections[db].cursor()

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
 
line 162, in cursor

cursor = util.CursorWrapper(self._cursor(), self)

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
 
line 134, in _cursor

return self.create_cursor()

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/utils.py", 
line 99, in __exit__

six.reraise(dj_exc_type, dj_exc_value, traceback)

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/__init__.py",
 
line 134, in _cursor

return self.create_cursor()

  File 
"/home/user1/sme-appname/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py",
 
line 138, in create_cursor

cursor = self.connection.cursor()

InterfaceError: connection already closed

 

I posted this on psycopg2 mailing list, but was told to contact you Django 
guys. Anyway, after tinkering around with some code in the django/db 
directory, I generated the following "fix" that helped most of our test 
cases to pass. The fix is in two files:

 

(1) django/db/backends/__init__.py   --> comment out the code that compares 
two autocommit values.

 

def close_if_unusable_or_obsolete(self):

"""

Closes the current connection if unrecoverable errors have occurred,

or if it outlived its maximum age.

"""

if self.connection is not None:

# If the application didn't restore the original autocommit 
setting,

# don't take chances, drop the connection.

#if self.get_autocommit() != self.settings_dict['AUTOCOMMIT']:

#print(" from within close_if_unusable_or_obsolete 
method ")

#print(" two autocommit settings not equal ")

#print(self.get_autocommit())

#print(self.settings_dict['AUTOCOMMIT'])

#self.close()

#return

 

if self.errors_occurred:

if self.is_usable():

self.errors_occurred = False

else:

print(" from within close_if_unusable_or_obsolete 
method ")

self.close()

return

 

if self.close_at is not None and time.time() >= self.close_at:

print(" from within close_if_unusable_or_obsolete 
method ")

self.close()

return

 

(2) django/db/__init__.py  --> simply call the recommended 
close_old_connections() as the comment in close_connection suggests, and 
comment out the old code.

 

 

def close_connection(**kwargs):

#warnings.warn(

#"close_connection is superseded by close_old_connections.",

#PendingDeprecationWarning, stacklevel=2)

## Avoid circular imports

#from django.db import transaction

#for conn in connections:

## If an error happens here the connection will be left in broken

## state. Once a good db connection is again available, the

## connection state will be cleaned up.

#transaction.abort(conn)

#print(" from within close_connection method ")

#connections[conn].close()

close_old_connections()

 

 

I am not a Django expert, much less a Django/db expert. Could somebody 
investigate whether something like this can be done and released in Django 
1.6.8? I am especially puzzled by why the two autocommit values are 
different. Should I do something else (in Django test 
client/settings/elsewhere) to make the two autocommit values the same? If 
this "fix" helps you guys, fine; we are interested in some proper fix 
coming from Django directly rather than patching things up ourselves.

 

Thanks,

Arun

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view th