Sounds good to me I'll try to get a wiki page up with the content you described by next weekend so that we can get this discussion going.
On Jun 21, 5:15 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Mon, Jun 21, 2010 at 10:41 PM, John Williams <druidjai...@gmail.com> wrote: > > There is a known issue with using various middlewares that check > > content-length consuming the content of iterators. There are many > > tickets up regarding the various incarnations of this behavior all of > > which appear to be stuck at about the same problem: what is the right > > way to fix this. I think it would be a good idea to get some > > discussion going on what is the appropriate way to address this issue. > > What would be allowable in a fix and what wouldn't be. Looking back > > in the discussion on this issue in the past on this group many > > solutions have been proposed. Various methods for solutions have been > > suggested: various methods of per view bypassing middlewares, > > requiring middleware authors to be aware of the issue and preventing > > them from clobbering a iterator to get content-length (various methods > > also such as a new attribute on HttpResponse changes in the > > middlewares to check _is_string), creation of an StreamingHttpResponse > > object It looks to me at a glance that where are a ton of relatively > > similar solutions. > > > This is quite the annoying issue, I was not aware of the issue until > > today and invested a solid 4-6 hours trying to find the issue that I > > assumed was something I was going wrong. I'm guessing I'm missing > > some of the nuances of the issue and potential things that might be > > broken by the change, but alot of the comments and changes suggested > > on #7518 feel pretty bikesheddy to me. At the minimum documenting > > this issue in the HttpResponse docs seems very appropriate if a > > solution can't be agreed upon, but perhaps some discussion can be had > > in this group and some consensus can be found about how to fix this. > > I completely agree that it would be good to fix this class of problem. > > The discussion around this problem is split over several tickets and > numerous mailing list discussions; what is required at this point is a > summary of exactly where past discussions have led. If you want to > contribute in this area, the best first step would be to provide this > summary. So -- start a page on the wiki in which you list all the > tickets, link all the mailing list discussions you can find, summarize > all the proposals that are currently on the table, and raise any > criticisms that have been leveled against those proposals. Once we > understand the current state of play, it becomes a lot easier to move > discussion forward. > > If you're looking for an example of what I'm describing, I would > suggest checking out [1] -- this is the summary page that Luke Plant > put together for the discussion about CSRF protection. > > [1]http://code.djangoproject.com/wiki/CsrfProtection > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
