title: Bottle server: HTTPResponse vs bottle.response
body: <p>I have a bottle instance whose server is set to a multi-threaded http server with a threadpool.</p>
  
  <p>We know one common way to for a bottle server to return from a route is</p>
  
  <pre><code>return HTTPResponse(status=200, body=json.dumps({'key':'value'})
  </code></pre>
  
  <p>I am also using an <code>after_request</code> hook, which tries to set some headers on the response by referring to <code>bottle.response</code>, and I found that inside the <code>after_request</code> hook code, it can no longer access that same <code>HTTPResponse</code> object, because whatever is referenced by <code>bottle.response</code> is a new response object. The object as returned by <code>HTTPResponse</code> is lost. </p>
  
  <p>And my theory is that it's because <code>bottle.response</code> references <code>LocalResponse()</code>, and is therefore thread-local. </p>
  
  <p>Assuming I cannot modify my after_request hook code, what can I do so that my after_request hook can still access the same <code>HTTPResponse</code> object?</p>
  
  <p>I can think of 2 ways:</p>
  
  <p>1) Instead of returning a new <code>HTTPResponse</code>, I just return a dictionary as the body: </p>
  
  <p><code>return json.dumps({'key','value'})</code> </p>
  
  <p>But how can I return a status code other than 200 now?</p>
  
  <p>2) Instead of returning a new <code>HTTPResponse</code>, do:</p>
  
  <p><code>bottle.response.status = 200; 
  bottle.response.body = json.dumps({'key':'value'}); 
  return bottle.response</code> </p>
  
  <p>Is 2) thread-safe? Will it cause issues for multiple requests hitting the server and the returned responses get mixed up in the after_request hook?</p>