I incorporated a good patch from ticket #6527 that cleaned up HttpResponse.__init__, which I have spent a lot of time looking at lately. This wasn't any of my work, but from my experience with HttpResponse, it looks like a good idea (and it makes the code more pleasant to look at).
HttpResponse now throws an exception when you try to set HttpResponse.codec with a value that it cannot use. Note: I am checking that the object has a "name" attribute, since that is what I am using so far to pass what codec is being used to smart_str, and others. I do not know if this is a good long term solution (this is what was in place before we started having codecs we could change), and I will probably investigate that in the future. I also improved test coverage for encodings -- I verify that responses in GBK and UTF-8 are encoded and decoded in their proper places (I found some arbitrary text encoded in GBK and used that, I hope it is not dirty). If anyone thinks a greater spread of coverage on that sort of thing is required, let me know and I will work on it. But it seems to me like it's doing what I want it to. I have also established the priorities and fallbacks for HttpResponseSendFile methods (as in, the way we actually deliver the files, whether directly in Python, through wsgi.file_wrapper, headers, etc). I also changed the associated setting to settings.HTTPRESPONSE_SENDFILE_METHOD, to reflect that it does not always contain the header. If this is set to None, we use handler methods, but otherwise the header gets set, and we do not send any content. If neither of these are available, we use the FileWrapper fallback in HttpResponseSendFile. This passes the test suite, but is untested on mod_python. I am also trying to figure out how to view the headers of a response with the Content-Disposition "attachment" header. In coming days, I will test the various kinds of headers (X-Sendfile etc) on Apache, nginx, and lighttpd. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
