On Fri, 2006-03-31 at 15:47 +0400, Ivan Sagalaev wrote: > I'm working on a patch (actually I use it for about a week locally) that > allows one to put an iterator as a content for HttpResponse. This is > intended primarily for large file-like objects that are fed to the user > incrementally without reading entirely into memory. This also allows to > invent some fancy iterators for output. I use one to constrain output > bandwidth for example... > > To finalize the thing I need some comments about design of HttpResponse. > > Currently HttpResponse looks a bit strange. It has 3 ways of accessing > its content: > > - get_content_as_string(charset) -- checks if content is unicode and > converts it to charset > - __str__ -- concatenates content with headers but doesn't check for > unicode and doesn't convert > - raw attribute content > > I did find that "get_content_as_string" and "content" both used. Didn't > find any explicit str(response) but it may be done implicitly anywhere. > > My current design is as follows: > - HttpResponse is converted to a new style class > - content becomes a property and is the only interface to the content > - on getting content HttpResponse checks for unicode and converts it to > DEFAULT_CHARSET > - get_content_as_string(charset) goes away, the only place where it is > used with non-default charset is a cache middleware that asks it in > utf-8. But it's still can be not utf-8 and cache middleware shouldn't > care anyway, all it wants actually is a byte-string, not certain charset
A relatively minor point: I would prefer to leave something like this method in place, since otherwise everybody has to implement it themselves if they care about HTTP compliance. The problem is the Accept-Charset header in the HTTP request (ยง14.2 of RFC 2616). If the client does not accept UTF-8 as the response encoding, you have to convert it to something they can accept. The WSGI spec implictly requires the back-end to make this conversion before returning the data from write(), from what I can see, which makes sense. Now, given, I'll bet that almost everybody is ignoring this requirement. But that isn't an excuse. As an implementation question, maybe a single get_content_as_string() method isn't correct (it does hurt streaming, I agree). A pass-through filter is kind of the write solution, I guess. This shouldn't be a blocker for your proposal in any case. I, for one, am happy to have a look at your code after it's done and see how we can graft character encoding conversion into it later. It won't be impossible and, like I said, it's a big omission in most servers these days anyway. Experience would suggest that it's not a huge requirement by clients, either, but it does play a useful role in East-Asian info processing, for example. > - __str__ will concatenate headers with content > - HttpResponse gets an attribute "stream" which is an iterator over > content. In the case of file response it's the file-like object and in > case of a string it's a list with single string. This is the iterator > that WSGI wants, BTW. > - HttpResponse.write raises an exception when HttpResponse was created > with an iterator and not a string. If it's a string it appends to it. I don't understand why this is necessary (raising the exception). What problem do you see here? > Any thoughts? I like your proposal. I particularly like the addition of the ability to stream. Haven't thought much about HttpResponse's implementation before, though, so I may be missing something. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
