Webサーバー上の特定のパスに誰かがアクセスしようとした場合、HTTP 204エラーコードを返したいのですが。私は、204エラーを返すようにウェブサーバーの1つを設定し、haproxyにそれをバックエンドとしてポイントすることができました。ただし、情報が送信されていないため、これはhaproxy自体から実行できるはずだと考えました。実際のWebサーバーを気にする必要はありません。
次のように204エラーを生成するバックエンドを作成してみました。
frontend ...
...
acl is_always204 path_beg /thisone
use_backend always204 if is_always204
...
backend always204
errorfile 404 /etc/haproxy-shared/errors/204.http
204.httpファイルには以下が含まれます。
HTTP/1.0 204 No Content
Cache-Control: no-cache
Connection: close
Content-Type: image/png
haproxyを起動すると、次のエラーが発生します。
parsing [/etc/haproxy/haproxy:51] : status code 404 not handled, error customization will be ignored.
私はこれについて間違った方向に進んでいるのではないかと思います。誰かがhaproxyに指定されたACLの一致に対して204を強制的に返す方法を提案できますか？
この状況では、204が正しいステータスコードだと思いますか？HAProxyのドキュメントによると、204と404はサポートされていない戻りコードです。これは403を返す必要があるようです。204は、リクエストがサーバーに配信されたことを示しています。
—
Anthony Fammartino 2014年
面白い。
—
マイケルハンプトン
Content-Typeこのコンテキストでは意味がありませんが、コンテキストが何であるかを理解するのに十分な情報がここにはありません。もちろんHTTP 204はめったに使用されません。204についての私の考えは、オリジンサーバーを使用することがまったく理にかなっているシナリオがある場合、おそらくオリジンサーバーがそれを送信する必要があるということです。
503エラーファイルにしてみましたか？実際のバックエンドサーバーはないため、HAproxyが503応答を提供する必要があります。