Avif server as octet-stream

[BleedingDev]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Same problem as for Gatsby: gatsbyjs/gatsby#31068
Or previously Remix: remix-run/remix#3771

What browser are you using? (if relevant)

Chrome 104, Edge 106

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

Wrong mime type for AVIF image from public folder.

Expected Behavior

Correct Content-Type, so image can be loaded.

Link to reproduction

https://github.com/pegak/nauc-me-it - you need to have pixel density 2x, run locally and check bg-landing.avif loading :)

To Reproduce

1. Put AVIF image into public folder.
2. Use that image (I use it from CSS as a background image).
3. Image does not work.
4. Check Network tab in Devtools.
5. Image is loaded, but with type octet-stream.

[SukkaW]

That's really weird.

I just use my browser to visit the URL directly, and the response header shows image/avif.

[BleedingDev]

And when you run it locally via yarn, yarn run dev? I think it is broken even when running yarn run build && yarn run start.

[SukkaW]

And when you run it locally via yarn, yarn run dev? I think it is broken even when running yarn run build && yarn run start.

@pegak Yes. I am able to reproduce the issue in local environment.

next.js/packages/next/server/serve-static.ts

Lines 23 to 28 in cc1f3b8

	export function getContentType(extWithoutDot: string): string | null {
	if (extWithoutDot === 'avif') {
	// TODO: update "mime" package
	return 'image/avif'
	}
	const { mime } = send

Next.js already implemented .avif handling (as a specific edge case). I will have a look at it to see what went wrong.

[SukkaW]

@pegak I have submitted a PR that will fix the issue: #39733

[BleedingDev]

Thank you very much! I must make some time to contribute to open source community to give something back! :)

[SukkaW]

Thank you very much! I must make some time to contribute to open source community to give something back! :)

@pegak Actually now you have a great opportunity to start with!

Your issue is caused by an upstream package send. It depends on another package mime to provide the content-type mapping.

The mime package has added avif in mime@2.4.7, but send is still using mime@1.6.0, hence your issue. You can submit a PR to send to help them update the mime dependency version!

A few notes:

• It seems that send is about to release a major version 1.0.0, thus there might be a dedicated developing branch. If there is a dedicated branch for the upcoming send@1.0.0, you should create your PR toward that branch, not master.
• From mime@1.6.0 to mime@2 is a major version bump, and mime@2 has introduced some breaking changes to its API, thus you should also help them to migrate.

[BleedingDev]

Thanks, looks like they already switched to mime-types, but thanks for the recommendation anyway. :)

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.