Support opaque response blocking when content type is recognized in OnDataAvailable()
Categories
(Core :: DOM: Networking, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox90 | --- | fixed |
People
(Reporter: edenchuang, Assigned: edenchuang)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
Opaque Response Blocking logic executes when a channel is OnStartRequest stage.
However, it might have enough data/information to recognize the actual content type. And the logic can be passed as followings types
Allowed_UnexpectedResponseHead
Allowed_FailtoGetMIMEType
Allowed_NotImplementOrPass
But the content type could be recognized during OnDataAvailable stage by sniffing with UnknownDecoder. The opaque response blocking should execute again when the actual content type is recognized.
|
Assignee | |
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 1•4 years ago
|
||
The original implementation concept of Opaque Response Blocking is trying to recognize the blocked or allowed content type in nsHttpChannel::CallOnStartRequest. However, the data could be not available at the moment for type sniffing. And nsUnknownDecoder could be used for type sniffing when OnDataAvailable is called.
So this patch targets this case and applying Opaque Response Blocking after the type is recognized by nsUnknownDecoder.
|
|
Assignee | |
Comment 2•4 years ago
|
||
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Comment 4•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3a282dee4cdc
https://hg.mozilla.org/mozilla-central/rev/27ab35eef920
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
Description
•