New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 809259 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 268640



Sign in to add a comment

JSON parser breaking sniffing in XSDB can theoretically block valid text/css responses

Project Member Reported by lukasza@chromium.org, Feb 5 2018

Issue description

It is possible to craft a text/css response that
1) contains a JSON parser breaker at the beginning
2) is still parsing fine as a stylesheet

For example:
    )]}'
    {}
    h1 { color: red; }

We should tweak XSDB's implementation so that it doesn't block such responses.
 
If I understand correctly, XSDB would only block these in cases where it's cross-origin but contains an empty/missing Content-Type header. And, per spec, those should be blocked anyway. (But they are not in Chrome.)

I've filed https://github.com/whatwg/html/issues/3457 on the spec to investigate whether allowing empty/missing Content-Type headers is a Chrome-only quirk which we can fix in Chrome, or whether it's something all browsers do which we need to codify in the spec and account for.
Hmm, sorry, maybe I misunderstood this bug, and it's about cases that have correct Content-Type headers but also have JSON parser breakers inside them. If so, please disregard my previous comment.
Owner: lukasza@chromium.org
Status: Started (was: Untriaged)
WIP CL @ https://chromium-review.googlesource.com/905634

RE: #c2 - yes this bug is about stylesheets served with the correct text/css MIME, but possibly blocked by XSDB because of JSON parser breaker at the beginning.
Status: Fixed (was: Started)

Sign in to add a comment