1824723 - Set the content type to the proper name when ObliviousHTTPChannel is used with POST

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Valentin Gosu [:valentin] (he/him)]

ObliviousHttpChannel::SetContentType currently forwards the content type to the inner channel, and we overwrite that with "message/ohttp-req" in AsyncOpen anyway.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1824723 - Set the content type to the proper name when ObliviousHTTPChannel is used with POST r=#necko

Depends on D173671

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1824723 - Also update TRR URI if network.trr.use_ohttp has changed r=#necko

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/69a871757246
Also update TRR URI if network.trr.use_ohttp has changed r=necko-reviewers,kershaw
https://hg.mozilla.org/integration/autoland/rev/f75638461adc
Set the content type to the proper name when ObliviousHTTPChannel is used with POST r=necko-reviewers,jesup

Comment 4

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/69a871757246
https://hg.mozilla.org/mozilla-central/rev/f75638461adc

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 9325369 [details]
Bug 1824723 - Also update TRR URI if network.trr.use_ohttp has changed r=#necko

Beta/Release Uplift Approval Request

• User impact if declined: DoH requests using OHTTP might be using the wrong domain causing the request to fail.
  This would happen only if the use_ohttp pref is changed after network.trr.ohttp.uri.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This changeset only affects users who have the network.trr.use_ohttp pref set - which is not on by default. We intend to do an experiment with it soon which is why I am requesting uplift.
• String changes made/needed:
• Is Android affected?: No

Comment 6

[Valentin Gosu [:valentin] (he/him)]

Comment on attachment 9325172 [details]
Bug 1824723 - Set the content type to the proper name when ObliviousHTTPChannel is used with POST r=#necko

Beta/Release Uplift Approval Request

• User impact if declined: Encapsulated OHTTP requests would not contain a Content-Type header. This might cause the requests to fail, depending on the behaviour of the OHTTP target.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This changeset only affects users who have the network.trr.use_ohttp pref set - which is not on by default. We intend to do an experiment with it soon which is why I am requesting uplift.
• String changes made/needed:
• Is Android affected?: No

Comment 7

[Dianna Smith [:diannaS]]

Comment on attachment 9325172 [details]
Bug 1824723 - Set the content type to the proper name when ObliviousHTTPChannel is used with POST r=#necko

Approved for 112.0b9

Comment 8

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e9fde18934b5
https://hg.mozilla.org/releases/mozilla-beta/rev/9d62b105a4dd