fetch assumes a url's object is always a Blob

[isonmad]

When it could be a MediaSource or a MediaStream. whatwg/url@1099bb2 So the following doesn't make sense:

Append Content-Length/blob’s size attribute value to response’s header list.
Append Content-Type/blob’s type attribute value to response’s header list.

What happens if someone tries to fetch one of the other kinds of blob: URIs?

[annevk]

That is a good question. The problem is that implementations do different things here, but we should indeed work on figuring this out. See also w3c/mediacapture-main#404.

Adding @foolip and @jan-ivar.

[jan-ivar]

Another reason media streams and sources should not be urls.

[annevk]

That would be ideal. @jan-ivar do you think we can eventually remove support? I suppose I could start by just adding a warning to Fetch about non-blob: usage (I don't think we can get ever rid of those).

[foolip]

For this issue specifically, I suppose one could simply treat it as an error and fail the request? What do implementations actually do?

If no implementers wants to move on w3c/mediacapture-main#404 then I suppose one alternative would be to go back to a separate protocol for the non-Blob blob: URLs, but that's a bit of churn too.

[annevk]

So

stream = new MediaStream();
streamURL = URL.createObjectURL(stream);
fetch(streamURL);

does indeed result in a TypeError in Chrome and Firefox (same for MediaSource), but what can streamURL be used for then? If you cannot fetch it, why support it to begin with?

[annevk]

Aaah, okay, so the way this works is that https://html.spec.whatwg.org/#concept-media-load-resource handles blob: URLs itself and doesn't pass anything toward Fetch. That indeed makes things easier here.