Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

How exactly did you run into this problem?

One of the configured corehttp.ServeOptions in our gateway added gzip compression if the client supports it via Accept-Encoding. That resulted in empty Content-Type headers when compression is enabled, and for some reason it resulted in a reverse proxy displaying the HTML index as plain text.

Ah, I see.

There is only one error case now, namely when the directory contents cannot be read. In that special case, the content-type will be text/plain while the HEAD request will return text/html. I'd say that is acceptable.

Since the previous version, #4233 got merged which introduces a new edge case: if ipfs-404.html is present, the directory index is not shown. However even for that case, text/html is appropriate.

Thanks!