Ensure ORB blocks requests with UNKNOWN_CONTENT_TYPE when the response is recognized as a blocked type after sniffing in OnDataAvailable
Categories
(Core :: DOM: Networking, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox109 | --- | fixed |
People
(Reporter: sefeng, Assigned: farre)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][orb:m2], [wptsync upstream])
Attachments
(2 files)
ORB doesn't block requests with UNKNOWN_CONTENT_TYPE, however it's possible that the response gets recognized as blocked type after sniffing in OnDataAvailable. We need to make sure this works as expected
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
The only test I can see failing is cache-put.https.any.js, and I think that it's correct and that it should fail.
https://treeherder.mozilla.org/jobs?repo=try&revision=0e50c7e91ba89b05fc5f22107c158ece5a775db5
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
To allow the test to perform opaque response filtering, we need to
bypass the ORB safelist check. This is done, by forcing the MIME type
retrieval to fail and the validation of partial first response to
succeed.
Depends on D161142
Assignee | ||
Comment 4•2 years ago
|
||
https://treeherder.mozilla.org/jobs?repo=try&revision=3036f96d50c215ab172a9c8dc24a80d186b3d9a3 thinks that wpt looks fine
Comment 7•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/235443c9a047
https://hg.mozilla.org/mozilla-central/rev/129b6d7f330e
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•