title: Rack middleware and thread-safety
body: <p>I have a custom rack middleware used by my Rails 4 application. The middleware itself is just here to default <code>Accept</code> and <code>Content-Type</code> headers to <code>application/json</code> if the client did not provide a valid information (I'm working on an API). So before each request it changes those headers and after each request it adds a custom X-Something-Media-Type head with a custom media type information.</p>
  
  <p>I would like to switch to Puma, therefore I'm a bit worried about the thread-safety of such a middleware. I did not play with instances variables, except once for the common <code>@app.call</code> that we encounter in every middleware, but even here I reproduced something I've read in RailsCasts' comments :</p>
  
  <pre><code>def initialize(app)
   @app = app
  end
  
  def call(env)
   dup._call(env)
  end
  
  def _call(env)
   ...
   status, headers, response = @app.call(env)
   ...
  </code></pre>
  
  <p>Is the <code>dup._call</code> really useful in order to handle thread-safety problems ?</p>
  
  <p>Except that <code>@app</code> instance variable I only play with the current request built with the current env variable :</p>
  
  <pre><code>request      = Rack::Request.new(env)
  </code></pre>
  
  <p>And I call <code>env.update</code> to update headers and forms informations.</p>
  
  <p>Is it dangerous enough to expect some issues with that middleware when I'll switch from <code>Webrick</code> to a concurrent web server such as <code>Puma</code> ?</p>
  
  <p>If yes, do you know a handful way to make some tests en isolate portions of my middleware which are non-thread-safe ?</p>
  
  <p>Thanks.</p>