Here we ensure that `=~` is applicable by calling `to_s` before
using it.

Close #2077

This commit ensures that all parameters of `Content-Type` are separated
with commas (`,`) instead of semicolons (`;`).

RFC 7231 (https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.5) says:

      Content-Type = media-type

    Media types are defined in Section 3.1.1.1. An example of the field is

      Content-Type: text/html; charset=ISO-8859-4

RFC 7231 3.1.1.1 (https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.1.1) says:

    Media types define both a data format and various processing models:
    how to process that data in accordance with each context in which it
    is received.

      media-type = type "/" subtype *( OWS ";" OWS parameter )
      type       = token
      subtype    = token

    The type/subtype MAY be followed by parameters in the form of
    name=value pairs.

      parameter      = token "=" ( token / quoted-string )

    The type, subtype, and parameter name tokens are case-insensitive.
    Parameter values might or might not be case-sensitive, depending on
    the semantics of the parameter name.  The presence or absence of a
    parameter might be significant to the processing of a media-type,
    depending on its definition within the media type registry.

    A parameter value that matches the token production can be
    transmitted either as a token or within a quoted-string.  The quoted
    and unquoted values are equivalent.  For example, the following
    examples are all equivalent, but the first is preferred for
    consistency:

      text/html;charset=utf-8
      text/html;charset=UTF-8
      Text/HTML;Charset="utf-8"
      text/html; charset="utf-8"

According to https://stackoverflow.com/a/35879320, it seems
that there was prior confusion in early RFCs over this. It appears `,`
was a mistake, and that `;` should always be used.

Most people probably haven't run into this because in order to trigger
this bug:

1. The Sinatra app needs to insert a `;` in the call to `content_type`
(such as `content_type "text/plain; version=0.0.4"`). If you omit the
`;` in the `Content-Type`, then everything is fine.

2. The client that talks to the app needs to reject `,` in the
`Content-Type`. Golang's `mime.ParseMediaType` appears to reject
`Content-Type` values that contain `,` but with the introduction of
prometheus/prometheus#15136 Prometheus v3
started to fail hard when this occurred.

Due to better validation in Rack: rack/rack#2298

See also

- rack/rack#2295
- rails/rails#54613

The Readme has already been updated to require rackup and puma as hard
dependencies (line 21). No need to also then recommend to install Puma
on line 37.

[ci skip]

It is already set to true for sinatra-contrib and rack-protection,
happened in #1537

…es (#2089)

This PR implements recent feature request related to static file
responses. It introduces a new configuration setting, `:static_headers`,
which allows developers to define custom headers that will be applied to
all static file responses served by `static!` -method.

Sinatra serves static files directly via `static!`, bypassing filters
and middleware. This makes it so that there is no good ways to add
headers like `Access-Control-Allow-Origin`, which are often needed for
CORS access (e.g., when using fonts or images on canvas).

Co-authored-by: Patrik Ragnarsson <[email protected]>

This is a temporary fix for #2113 until rack/rack#2316 is merged.

Fixes #2113.

This reverts commit fa99a21.

It causes problems, if you have an app like this

    class FooApp < Sinatra::Base
      get "/" do
        "hello foo"
      end
    end

and map it like this in config.ru

    map("/foo") { run FooApp.new }

`GET /foo` returns 404, which was not the case before. 
`GET /foo/` does reach the app.

Reported at #2113 (comment)