私はミニミニマリストのhttpサーバーのプロトタイプ（boost asioの例に大きく影響を受けています）を作成しましたが、現時点ではサーバーの応答にhttpヘッダーを入れておらず、html文字列のコンテンツのみを入れています。驚くべきことに、それはうまく機能します。
その質問では、OPはhttp応答の必要なフィールドについて疑問に思い、コメントの1つは、それらがサーバー側からはそれほど重要ではない可能性があると述べています。
現時点では、バイナリイメージファイルまたはgzip圧縮ファイルに応答しようとはしていません。その場合、httpヘッダーが必須であると思います。
しかし、テキストのみの応答（html、css、およびxml出力）の場合、サーバーの応答にhttpヘッダーを含めないことは問題ありませんか？考えられるリスク/エラーは何ですか？
少なくとも、ステータス行と日付を含むヘッダーを提供する必要があります。
多くのプロトコルパーサーを書いた人として、私はあなたにお願いします、私のデジタルメタファーの膝の上で、あなたの好きなブラウザがあなたにそれをやめさせるという理由だけで仕様を完全に無視しないでください。
生成されるデータが正しい限り、機能が最小限のプログラムを作成することはまったく問題ありません。応答の先頭に3行追加するだけなので、これは大きな負担にはなりません。そして、それらの行の1つは空白です！応答データを仕様に一致させる2行のすばらしいコードを書くのに数分かかります。
実際に提供する必要のあるヘッダーは次のとおりです。
Connection: close、ヘッダーに追加します応答とともにコンテンツタイプを送信しないことを選択できますが、クライアントがデータをどう処理するかを知らない可能性があることを理解する必要があります。クライアントは、それがどのような種類のデータであるかを推測する必要があります。ブラウザは、それを表示するのではなく、ダウンロードされたファイルとして扱うことを決定する場合があります。自動化されたプロセス（誰かのbash / curlスクリプト）は、データが予期されたタイプではないと合理的に判断する可能性があるため、データを破棄する必要があります。
HTTP/1.1仕様セクション3.1.1.5から。コンテンツタイプ：
ペイロード本文を含むメッセージを生成する送信者は、囲まれた表現の意図されたメディアタイプが送信者に不明でない限り、そのメッセージにContent-Typeヘッダーフィールドを生成する必要があります（SHOULD）。Content-Typeヘッダーフィールドが存在しない場合、受信者は「application / octet-stream」（[RFC2046]、セクション4.5.1）のメディアタイプを想定するか、データを調べてそのタイプを判別できます（MAY）。