Skip to content

Unclear when CORB requires nosniff #778

Closed
@jakearchibald

Description

@jakearchibald

https://fetch.spec.whatwg.org/#corb-check.

  1. If response’s status is 206 and mimeType (ignoring parameters) is a CORB-protected MIME type, then return blocked.

Step 4 checks the mime type for 206 responses whether nosniff is set or not.

  1. Let nosniff be the result of extracting header values from the first header whose name is a byte-case-insensitive match for X-Content-Type-Options in response’s header list.
  2. If nosniff is not failure and mimeType (ignoring parameters) is a CORB-protected MIME type or text/plain, then return blocked.

Note: CORB only protects text/plain responses with a X-Content-Type-Options: nosniff header. Unfortunately, protecting such responses without that header when their status is 206 would break too many existing video responses that have a text/plain MIME type.

The note suggests that only text/plain responses require the nosniff header to allow CORB, but from step 6 it seems like all types require nosniff in order to be protected, unless the response is 206.

It seems weird that 206 responses don't require nosniff. A note explaining why would be useful.

Maybe I'm getting confused because step 5 isn't clear on what should happen if the response does not have a X-Content-Type-Options header.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions