Changing HTTP Response code does not work

[fossecode]

Hi! First of all, awesome extension 💯 👍

I am however unable to modify the HTTP response code:

[sirdarckcat]

It's possible it's a DevTools issue, but I'll add a test to confirm :-)

[sirdarckcat]

yep, it's broken.

reproduced by going to: http://evilwebsite.com/shell.html and typing

(async x=>{print((await fetch("")).status)})()

changing from 200 to 201 returns 200

[sirdarckcat]

The value flows from here:

tamperchrome/v2/background/src/request.ts

Line 89 in 1ad8700

modified.status = obj.status;

to here:

tamperchrome/v2/background/src/request.ts

Line 146 in 1ad8700

responseCode: response.status || this.status || 0,

and ends in https://chromedevtools.github.io/devtools-protocol/tot/Fetch/#method-fulfillRequest

weird :)

[sirdarckcat]

traced it to the API call, and 201 is sent correctly, but the javascript code still sees value 200.

[sirdarckcat]

Seems like Chrome recognizes the new status code, as it behaves differently when changing it from 200 to 302 (it only allows a Location redirect with 3XX and fails if the status is 200). It's probably a bug in Chrome.

[sirdarckcat]

And it seems like Chrome doesn't look at the status of intercepted requests
https://source.chromium.org/chromium/chromium/src/+/master:content/browser/devtools/devtools_url_loader_interceptor.cc;l=1080;drc=63bc8056437ba6b1698c01e8f55e8fd187926640

There's an explicit check for head->headers->IsRedirect which explains why they make a difference.

Looking at how the url_fetcher gets the headers see why the status is different.

[sirdarckcat]

my current theory is that the headers come from the response_info_ object, while the response code comes from the request_job https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/url_fetcher_core.cc;l=423;drc=63bc8056437ba6b1698c01e8f55e8fd187926640

[sirdarckcat]

this test seems to explain how the interception between devtools and the url req factory is done
https://source.chromium.org/chromium/chromium/src/+/master:services/network/url_loader_unittest.cc;l=4781;drc=69d394f9899f1f39911df8e50a9e3d86d25dc1a4

[sirdarckcat]

so, networkserviceclient is the one that brokers the connection between the url_loader and devtools, it seems.
https://source.chromium.org/chromium/chromium/src/+/master:content/browser/network_service_client.cc;l=229;drc=d6edf4bb211798b0aa0b656dfb06614cfea043e3

[sirdarckcat]

and here seems to be where things are overriden.
https://source.chromium.org/chromium/chromium/src/+/master:services/network/url_loader.cc;l=1622;drc=63bc8056437ba6b1698c01e8f55e8fd187926640

or actually here to be more accurate:
https://source.chromium.org/chromium/chromium/src/+/master:services/network/url_loader.cc;l=2010;drc=63bc8056437ba6b1698c01e8f55e8fd187926640

[sirdarckcat]

mojo's documentation
https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/mojom/network_context.mojom;l=185;drc=63bc8056437ba6b1698c01e8f55e8fd187926640

[sirdarckcat]

looking at the behavior of webRequestBlocking - it appears that it gets modified at a different layer, here:
https://source.chromium.org/chromium/chromium/src/+/master:extensions/browser/api/web_request/web_request_proxying_url_loader_factory.cc;l=973;drc=63bc8056437ba6b1698c01e8f55e8fd187926640;bpv=1;bpt=1

[sirdarckcat]

So, the two mojo services are:

• network_service
• network_context

The difference is explained here:

// Callback interface for NetworkContext when routing identifiers aren't
// available. Otherwise generally callbacks from the network service go on
// NetworkServiceClient.

[sirdarckcat]

The request_info_ is reset here:
https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/url_request.cc;l=886;drc=63bc8056437ba6b1698c01e8f55e8fd187926640;bpv=1;bpt=1

and the job is set here:
https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/url_request.cc;l=611;drc=63bc8056437ba6b1698c01e8f55e8fd187926640;bpv=1;bpt=1

I'm not sure why this is done this way.

[sirdarckcat]

will file a bug with chrome, with a small reproducer, and see if they can investigate

[michahell]

Dang... this is the one thing that I needed to work to fake/mock backend errors and it doesnt work 😢
but really nice tool nonetheless

[joaobibiano]

Hi guys,

There's something that I can help you with?

This feature seems to be amazing testing.

[sirdarckcat]

it's complicated, it'll probably be easier to remove this feature from Tamper.dev (or restrict it to just the status code that have side effects - so, redirects)

[sirdarckcat]

https://bugs.chromium.org/p/chromium/issues/detail?id=1275920