Don't go through the test client, in that case. If you modify the behaviour of the test client, and then make a request through it, you are not testing your code against the input that it will actually have to handle.
You shouldn't be trusting the test client to construct HTTP requests in exactly the same way as the WSGI client. It does a good enough job to get the request parameters into your view, but it certainly isn't the same as what you would get from a real request.
The purpose of the test client is to shield you from all of the messy details of the real request and response objects, and just let you test how your views respond to input parameters. In your case, though, you need to test those details.
You should be constructing an HTTPRequest object the same way that Django would -- use as many Django functions as you need to build it, and then call your view, or your middleware, directly with that HTTPRequest object. If your view should be raising an exception, then use assertRaises to test it. If it should return an HTTPResponse with the status code set to 500, then test that -- or test them together with a custom assert method, if you need to.