Skip to content

Specify Data URL media-type as application/octet-stream when mimeType not available#220

Open
yezhizhen wants to merge 1 commit into
w3c:mainfrom
yezhizhen:patch-1
Open

Specify Data URL media-type as application/octet-stream when mimeType not available#220
yezhizhen wants to merge 1 commit into
w3c:mainfrom
yezhizhen:patch-1

Conversation

@yezhizhen
Copy link
Copy Markdown
Member

@yezhizhen yezhizhen commented May 13, 2026

While implementing FileAPI in Servo, servo/servo#44897
I notice we fail to pass some readAsDataURL WPT tests:

  1. result for Blob with unspecified MIME type
  2. readAsDataURL result for empty Blob

It seems that spec is not aligned with test expectations. WebKit, Chromium, Gecko would fallback to application/octet-stream.

Part of #104

Implementation commitment:

  • WebKit
  • Chromium
  • Gecko
    And Servo will do this from now on.

Preview | Diff

@yezhizhen
Copy link
Copy Markdown
Member Author

cc @xiaochengh

pull Bot pushed a commit to AKJUS/servo that referenced this pull request May 14, 2026
…m` for unspecified Blob type (servo#44897)

We didn't produce valid RFC2397 format. Earlier, when Blob type is
empty, we would produce
`data:base64,...`, but the correct format should be `data:;base64,...`

However, just doing that won't pass the test, as spec is not aligned
with browser behaviours.
All browsers follow the existing tests behaviour.
I opened w3c/FileAPI#220.

Testing: Passing `reading-data-section/filereader_readAsDataURL.any.js`
for worker and main window.

---------

Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
@yezhizhen
Copy link
Copy Markdown
Member Author

Updated test for FileReaderSync to reflect this, mirroring existing FileReader tests:
web-platform-tests/wpt#59880

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant