1209102 - fetch() should not allow redirects to data URIs

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Ben Kelly [:bkelly, not reviewing]]

See:

  https://github.com/whatwg/fetch/issues/111

This probably effects other code as well since more things are using the fetch spec now.  See bug 1018872.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Wait, why do we want to disallow the redirect instead of just making it a opaque response?  There doesn't seem to be any actual reasoning to this effect in the github issue.

It seems to me like we should have as few special-cases in the platform as possible.  Just because Blink happens to special-case all sorts of URI schemes everywhere and hence is inconsistent in terms of which schemes it supports in which context doesn't mean that we should spec that behavior or force everyone else to implement such spaghetti special-casing.

Comment 2

[Anne (:annevk)]

Does Blink really have that many special cases? I guess we could revert back to making it opaque. I figured that since we were planning on aligning with Blink with regards to data URLs we could align on this front as well, but perhaps that wasn't as a principled decision as it should have been.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Does Blink really have that many special cases?

As far as I can tell, it does, though they've been whack-a-moling them a bit.  They support various things from blob: URIs but not data: URIs, and it's totally inconsistent which things those are, and they keep changing it.

> I figured that since we were planning on aligning with Blink with regards to data URLs

With regard to their handling in iframes, no?  Not their entire insanity where they have to manually change every callsite that might be fetching a URI to specially handle data: and therefore handle it or not handle it in completely random ways!

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

This might have never been spec'd, but we should double check.

Comment 5

[Anne (:annevk)]

Note that I'm still not convinced this makes data URLs magic since either way the redirect logic in the specification will have to handle them explicitly (and that's only a single location, not every callsite), but as I mentioned I'm happy to change this back. Hopefully we can convince Chrome to do the same.