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">' % {
> 'cls': self.__class__.__name__,
> 'status_code': self.status_code,
> 'content_type': self['Content-Type'],
> }
And after deleting an object in DRF sends empty response with HTTP204 and no
'Content-Type' header. I was trying to log outgoing response and got KeyError
here.
So I have two questions:
1. Is this intentional? Do all responses in Django have 'Content-Type' header
and should DRF be aware of it?
2. Why not use `str.format` here? To avoid errors like this, `dict` subclass
with `__missing__` method could be used.
--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/39F85D40-019C-411A-BCA7-402E338EA527%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
What is the contract of a cache backend regarding errors?
Hello, I am considering writing a cache backend for Django based on a recent Couchbase SDK (2.0+). While it is quite straightforward to write, I would like to know what is expected from a cache backend when errors happen. With my experience using the python-memcached backend, my understanding is that: * On read operations, any errors result in a "None" return value (as if the value was not found); * On write operations, errors are silenced, with one exception; * On an "add" operation, if e.g. a network error has happened, "0" is returned instead of "False". That lets a client make a distinction between such errors and the key already existing. Is that understanding accurate? In particular, is the third point contractual? Thank you in advance. -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/12bdf965-eba7-4f81-8ce0-bd8803d4d726%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: delegating our static file serving
I started looking into this but have progressed slowely. At first I put the whitenoise project into the contrib folder of django. Tim Graham suggested not to change much of the integration with the old WSGI interface, so I think the new middleware way would be alright too. On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote: > I'd like to work together with Dave to develop a proof of concept that > integrates whitenoise into Django. I spent about an hour looking through > whitenoise and our own static file serving code, and I think integrating > whitenoise will yield a simpler user experience with about the same amount > of code as have now. > > Essentially, we'd recommend adding something like this to existing wsgi.py > files (it would be in the default startproject template) > > from whitenoise.django import DjangoWhiteNoise > application = DjangoWhiteNoise(application) > application.add_files( > settings.MEDIA_ROOT, prefix=settings.MEDIA_URL) > > which would have the benefit of working out of the box in production too, > I think. Of course, you could disable that based on settings.DEBUG or some > other toggle. > > We could then deprecate: > > * django/contrib/staticfiles/views.py > * django/contrib/staticfiles/management/commands/runserver.py > * django/contrib/staticfiles/handlers.py > * django/views/static.py > > Any objections to doing further investigation in this area? > As I tried to remove the suggested deprecated files I encoutered the dependency from StaticLiveServerTestCase to StaticFilesHandler. StaticLiveServerTestCase allows the execution of tests without using collectstatic first which I think is not possible in Whitenoise. Do we add this functionality in Whitenoise or force the user to use collectstatic? Whitenoise depends on the staticfileapp and maybe a merge of the two components would be cleaner. I wanted to do this as a project in my university and would like to offer my help. -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87756f6f-2629-444c-9cdf-1b3ae76241ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
