If I understand https://html.spec.whatwg.org/#link-type-stylesheet correctly, cross-origin responses should only result in a load for codes 2XX and content-type text/css. If my understanding is false, there still is a compatibility problem as Firefox (and Chromium) behave different for various responses. Example differences: - 200 with content-type text/html (https://observer.sectec.rocks/opg/link-stylesheet/?url=https://echo.sectec.rocks/echo/?content-type=text/html) WebKit load, Firefox error - 3XX with content-type text/css and no location header (https://observer.sectec.rocks/opg/link-stylesheet/?url=https://echo.sectec.rocks/echo/?content-type=text/css&ecohd_status=302) WebKit load, Firefox error
Chrome seems to match the WebKit behavior in both cases, right? That is, Chrome loads both stylesheets, without any errors.
Pull request: https://github.com/WebKit/WebKit/pull/18122
About the “200 with content-type text/html” case: Testing and code inspection show that WebKit doesn’t actually process that https://echo.sectec.rocks/echo/?content-type=text/html resource — it’s just that currently (due to the order of a particular condition in the code), the reason WebKit doesn’t process it is that the resource is empty (has no HTTP body/data). But I guess, for developer ergonomics, it’s arguably better to still log a console message even when the resource is empty — so I opened https://github.com/WebKit/WebKit/pull/18122 with a patch which does that. I haven’t investigated the “3XX with content-type text/css and no location header” case yet, but it seems likely that the behavior there may also be due to the fact the resource is empty. I can look into it later, but in the meantime you might want to put together an additional test which serves a non-empty resource for that case — and see if you get different behavior.
> I haven’t investigated the “3XX with content-type text/css and no location header” case yet, but it seems likely that the behavior there may also be due to the fact the resource is empty. I can look into it later, but in the meantime you might want to put together an additional test which serves a non-empty resource for that case — and see if you get different behavior. This should probably be a separate bug too.
> > I haven’t investigated the “3XX with content-type text/css and no location header” case yet, but it seems likely that the behavior there may also be due to the fact the resource is empty. > > This should probably be a separate bug too. Agreed yeah — Jannis, could you please raise a separate bug for the 3XX/non-2XX case?
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/42147
I created another bug report here: https://bugs.webkit.org/show_bug.cgi?id=262030 Here are testcases for 200 with bodies: - text/html + css body: https://observer.sectec.rocks/opg/link-stylesheet/?url=https://echo.sectec.rocks/echo/?content-type=text/html&ecocnt_css=p%20{color:%20red;} -> error in WebKit and Firefox, Load in Chromium - text/html + image body: https://observer.sectec.rocks/opg/link-stylesheet/?url=https://echo.sectec.rocks/echo/?content-type=text/html&ecocnt_img=width=200,height=300,type=png -> error in WebKit and Firefox, Load in Chromium - no content-type + image body: https://observer.sectec.rocks/opg/link-stylesheet/?url=https://echo.sectec.rocks/echo/?ecocnt_img=width=200,height=300,type=png -> load in all browsers
<rdar://problem/116112223>
Committed 268535@main (c31f4e6a298d): <https://commits.webkit.org/268535@main> Reviewed commits have been landed. Closing PR #18122 and removing active labels.
It looks like the WPT pull request was never merged. Could you please check if it's still good to merge and do so? It would be nice to have this test up on wpt.live and wpt.fyi.
Thanks Thomas for the heads up. This has been done.