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

@yezhizhen yezhizhen commented May 13, 2026

Copy link
Copy Markdown
Member

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
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

1 participant