An easy way to see where close
is being called is to just subclass StringIO
and put a breakpoint in the close function.
class CustomStringIO(StringIO):
def close(self):
import pdb; pdb.set_trace()
super(CustomStringIO, self).close()
The stack for this is
-> response = self.client.post("/test/", {'data': data, 'filename': 'out.jpg'})
...\venv\lib\site-packages\django\test\client.py(463)post()
-> response = super(Client, self).post(path, data=data, content_type=content_type, **extra)
...\venv\lib\site-packages\django\test\client.py(297)post()
-> return self.request(**r)
...\venv\lib\site-packages\django\test\client.py(406)request()
-> response = self.handler(environ)
...\venv\lib\site-packages\django\test\client.py(119)__call__()
-> response.close() # will fire request_finished
...\venv\lib\site-packages\django\http\response.py(233)close()
-> closable.close()
> \testapp\views.py(11)close()
-> super(CustomStringIO, self).close()
It looks like the test client is closing the response, which in turn calls close on FileWrapper
which then calls close on StringIO
. This is all before you actually get to response.content
.
Is there a reason why you need FileWrapper
? As HttpResponse
takes in string content and base64.decodestring
returns a binary string, it seems you could just pass data
directly to HttpResponse
instead of having to create a StringIO
and FileWrapper
.