On Mar 12, 2009, at 3:06 PM, Jonathan Vanasco wrote:
> > in .9.6 setting headers like this worked: > response.headers['Content-Type'] = 'application/ms-excel' > > in .9.7 , anything i do to them is met with this > AttributeError: You cannot access Response.unicode_body unless charset > is set Response actually determines the charset value lazily via the Content- Type header -- since you didn't specify one its value was reset. response.content_type is the smarter, shorthand version, that maintains the charset. It looks like the old Response actually had the same behavior, it was just less strict about returning unicode values when there was no charset. Also, assuming you returned the result of a render call -- render returns unicode now whereas before it returned a raw str. Since there's a few things involved here I don't think we can make it seamlessly backwards compatible. This would also work: response.headers['Content-Type'] = 'application/ms-excel; charset=%s' response.charset But this is obviously nicer: response.content_type = 'application/ms-excel' > response.content_disposition 'works' in that it doesn't cause an > error. but it's not respected. > > i've yet to test headers for 'cache-control' , 'pragma' , and > 'expires'. > > needless to say, this is a very annoying bug/behavior change. Apparently Response allows assignment of arbitrary attributes, so even though it doesn't support content_disposition, it didn't fail. I have no idea why it does this, I'd rather it fail fast. We'll have to ask Ian. I've added actual .content_disposition support to WebOb trunk. -- Philip Jenvey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
