Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORB should not block application/dash+xml videos #886

Closed
anforowicz opened this issue Mar 29, 2019 · 8 comments
Closed

CORB should not block application/dash+xml videos #886

anforowicz opened this issue Mar 29, 2019 · 8 comments

Comments

@anforowicz
Copy link
Contributor

https://crbug.com/947498 points out that CORB incorrectly blocks dash videos.

I am not sure what would be the authoritative source here, but "application/dash+xml" is suggested by both:

We probably just need to tweak WPT tests and the spec to exclude "application/dash+xml" (just like "image/svg+xml" is excluded).

PS. We might also consider excluding all of "image/", "video/", "audio/", "font/" so that when a new "image/futureImageFormat+xml" is introduced, it is not affected by CORB. OTOH, this wouldn't help in this case (why application/dash+xml rather than video/dash+xml?) and we probably should tackle this as a separate issue (?).

/cc @annevk @csreis

@annevk
Copy link
Member

annevk commented Mar 30, 2019

Why font/?

But also, given how feasible #721 seems I'm much more interested in trying to advance that.

@anforowicz
Copy link
Contributor Author

Why font/?

Ooops... I keep forgetting that fonts are CORS-bound...

But also, given how feasible #721 seems I'm much more interested in trying to advance that.

I agree that #721 sounds like a promising long-term plan, but it might still make sense to explicitly note the application/dash+xml exception in the short-term (before we have spec changes + WPT tests + one browser implementation for #721). So, I think for now it might still make sense to land the small spec change in #887 - WDYT?

@annevk
Copy link
Member

annevk commented Apr 5, 2019

So the dilemma is that I think there's no longer two implementers interested in CORB in its current form, although Apple hasn't really weighed in here one way or another I think. @rniwa?

@rniwa
Copy link

rniwa commented Apr 5, 2019

@annevk : Hm... I think we want something like CORB but we haven't studied the current proposal of CORB yet so I can't really comment.

@annevk
Copy link
Member

annevk commented Apr 8, 2019

@rniwa for what it's worth, the sketch I put up at #721 (comment) is what we are planning on doing in Firefox.

@rniwa
Copy link

rniwa commented Apr 13, 2019

@annevk : Okay, sorry, we haven't been engaging in the discussion as much lately but I'm hoping to get back on it soon.

@annevk
Copy link
Member

annevk commented Apr 13, 2019

No worries, we can discuss it in Toronto later this month as well if there's some free time.

@anforowicz
Copy link
Contributor Author

As pointed out by @acolwell, original CORB implementation was done before OOR-CORS and therefore had to cover both no-cors and CORS. Once CORB (as spec-ed!) covers only no-cors requests, then possibly application/dash+xml shouldn't mater at all, because 1) Chrome/desktop doesn't have native support for DASH in video.src and 2) other implementations (e.g. Chrome/Android or Safari) only allow same-origin DASH.

Based on the above, we should just mark the current bug as closed. (Possibly following up separately on universally requiring CORS for DASH/HLS/etc).

PS. From ORB side this was discussed in annevk/orb#23 (comment) and in annevk/orb#20

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

No branches or pull requests

3 participants