Decoding headers possible error

[sonic182]

This example simulates the same headers parsing that Mint does:

headers = ~s"HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0,public
Pragma: no-cache
Content-Type: text/xml
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Microsoft-IIS/8.0
Set-Cookie: PHPSESSID=vtae57cm6mj673qhmn5a73bm86; expires=Thu, 07-Jul-2022 13:27:55 GMT; path=/
Strict-Transport-Security : 4838400
Date: Wed, 06 Jul 2022 09:41:45 GMT
Connection: close

"

defmodule Parser do

  def parse(data, res \\ nil) do
    type = case res do
      nil -> :http_bin
      something -> :httph_bin
    end
    case :erlang.decode_packet(type, data, []) do
      {:ok, {:http_response, version, status, status_text}, rest} ->
        res = %{
          status_code: status,
          headers: [],
          body: nil
        }
        parse(rest, res)

      {:ok, {:http_header, _size, _atomkey, key, val}, rest} ->
        res = %{ res | headers: res.headers ++ [{key, val}]}
        parse(rest, res)

      {:ok, :http_eoh, body} ->
        %{ res | body: body}

      other ->
        IO.inspect "--- other"
        IO.inspect other
        IO.inspect data

    end
  end
end

IO.inspect  Parser.parse(headers)

The error is when parsing the header Strict-Transport-Security : 4838400 which has an space before the colon

The RFC says that it should't happen and :erlang.decode_package works correctly displaying an error in that case but... shall mint handle it maybe? to make it more accessible for some servers?

[ericmj]

We have no plans to deviate from the HTTP specification and since the specification even says it can lead to security issues, even more so in this case.

From RFC9112 section 5.1:

No whitespace is allowed between the field name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon. A proxy MUST remove any such whitespace from a response message before forwarding the message downstream.

[sonic182]

RFC9112

Thanks for your very precise response :rocket: