No 'Content-Type' header in response

Hi! I'm using Django 1.10.2 and Django-Rest-Framework 3.5.3. I noticed, that HttpRequest.__repr__ method relies on 'Content-Type' header: > class HttpResponse(HttpResponseBase): > ... > > def __repr__(self): > return '<%(cls)s status_code=%(status_code)d, "%(content_type)s">' % {

Re: HttpResponse.headers public property

I didn't realise there's a difference. Personally, I think response.items() is better. Although it would be much nicer if headers could be accessed in the same way in HttpRequest and HttpResponse, so a ticket you posted earlier is quite relevant. In my opinion 'HEADERS' property (or lower-case '

Re: HttpResponse.headers public property

Given ticket is about HttpRequest headers, I was writing about HttpResponse. Am I missing something? > On 8 Nov 2016, at 19:56, Tim Graham wrote: > > Here's an accepted ticket for the idea: > https://code.djangoproject.com/ticket/20147 > > It looks like there's rough consensus but a complete

HttpResponse.headers public property

Hi! Is there a reason why HttpResponse doesn't have public 'headers' property? I want to log all response headers in tests and don't want to access private '_headers' property. Implementation is very simple and will prevent user from changing actual headers (if that was intended in the first pl

Re: Feature suggestion: Option to suppress system checks in commands

Hi, wouldn't it be easier to create special settings for cron? Something like that: # myprj/settings/cron.py from myprj.settings import * SILENCED_SYSTEM_CHECKS = ... And in cron: ... python manage.py --settings=myprj.settings.cron > On 30 Sep 2016, at 11:31, Vlastimil Zíma

Re: Feature suggestion: Option to suppress system checks in commands

Hi, wouldn't it be easier to create special settings for cron? Something like that: # myprj/settings/cron.py from myprj.settings import * SILENCED_SYSTEM_CHECKS = ... And in cron: ... python manage.py --settings=myprj.settings.cron > On 30 Sep 2016, at 11:31, Vlastimil Zíma wrote: > > Hi

Re: Struggling newbie

Could you provide you settings file? I think it may be an error in settings. > On 24 Aug 2016, at 23:12, jsjazzj...@gmail.com wrote: > > I am running python3.4 with Django in virtualenv. When I execute python > manage.py runserver I continue to get "sqlite3.NotSupportedError: URIs not > suppor

Re: Simulating timeouts on client with django.test.client.Client

I've actually tried adding ThreadingMixIn to WSGIServer and it worked like a charm in my case. Here's the code I added: from django.test.testcases import LiveServerThread, QuietWSGIRequestHandler from django.core.servers.basehttp import WSGIServer from socketserver import ThreadingMixIn class T

Re: Simulating timeouts on client with django.test.client.Client

equest). > > I didn't find any information about how to start live server with multiple > threads in Django docs or LiveServerTestCase code, is that even possible? > > > On 24 Aug 2016, at 17:26, GMail > wrote: > > > > I didn't try LiveServerTestCase y

Re: Simulating timeouts on client with django.test.client.Client

#x27;m thinking about using 'manage.py runserver' manually, because it seems it would do the same thing as LiveServerTestCase and also server with multiple threads. But that solution doesn't seem right to me. > On 24 Aug 2016, at 21:20, GMail wrote: > > So I've trie

Re: Simulating timeouts on client with django.test.client.Client

Error instead of "HTTP 202 Accepted" (because thread is busy processing first request). I didn't find any information about how to start live server with multiple threads in Django docs or LiveServerTestCase code, is that even possible? > On 24 Aug 2016, at 17:26, GMail w

Re: Simulating timeouts on client with django.test.client.Client

swer to your needs? > > On Wednesday 24 August 2016 17:10:42 GMail wrote: >> "Players" are backends (Django) and load balancer that proxies all user >> requests on one of the backends. In my case load balancer has small >> backend timeout (default is 3 sec, prefera

Re: Simulating timeouts on client with django.test.client.Client

"Players" are backends (Django) and load balancer that proxies all user requests on one of the backends. In my case load balancer has small backend timeout (default is 3 sec, preferable is 1 sec) and it will send the same request (with the same X-Request-Id header) to another backend after this

Re: Proposal: drop Python 2.5 support in Django 1.5

+1 Regards, Kok HOOR Sent from my iPad On Dec 11, 2011, at 10:06 AM, Adrian Holovaty wrote: > On Sat, Dec 10, 2011 at 6:37 PM, Alex Gaynor wrote: >> 2.5 is EOL and no longer receiving security patches even, it is >> *irresponsible* of us to support it (I claim). ANyways +1 > > This is a

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

I would like to say congrats and thanks to all those who have put in hard work on the Python 3 port. It is a very socially responsible thing to do, as django is one of the major open-source python framework, and will certainly act as encouragement for other python-based open-source to do the sam