Do you want to modify the data that is coming over the wire? It would have to be after onBeforeSendHeaders. 

Basically. I want modify the data before really load it. If possible, edit after too.

I think about two options:
- onBeforeSendHeaders: break the content download, download via ajax, edit and return it;
- onCompleted: break the real content return, edit and return it;

Changing title to reflect the feature request.

We intentionally left this functionality out of the initial release. We haven't decided whether to add it yet.

I think that this feature is too great to many cases...

For me is because I want make a Code Coverage for JS, then I need to parse and edit the code, before to send to client (currently it is impossible).

But it can be useful to make a "anti-virus", "anti-popup", and maybe a JS optimization or to generate stats, I don't know...

(Marking as Available to get out of triage queue - not necessarily as an indication that we will implement the feature)

Also useful to modify resources that are fetched by plugins, such as flash config files, etc or parsed directly by the browser (e.g images)

 Issue 114773  has been merged into this issue.

Any news on this? I think this could be great for web development, especially mocking ajax requests.

I am also really interested in seeing this. Especially if this would mean, that we can also read the responseBody content.

I'd really appreciate it if this gets implemented, too!

I myself would like to see this feature implemented. The app I currently have would benefit tremendously from this, almost 50% of my code would be reduced if this feature was available. Thanks!

Any news?

I'm also waiting for this feature!

I also want it. It would be really really really helpful to handle with json reacived by ajax requests!

I'd also find this feature quite useful

We hear you. Unfortunately, this request is not trivial.

Regarding reading the Response Body: This is challenging from a performance perspective. Your extension would not want to get a multiple gigabyte blob if you download a DVD image. Presenting a file handle and a "Read from bytes 0 to byte xx.xxx" is also very challenging because of the question when the data can be released.

Regarding modifying the Response Body: Here the challenge is Chrome's architecture. Chrome has multiple layers that build on each other:
- Request layer
- Cache
- Network layer
We cannot hook into the network layer because the WebRequest API sees only the request abstraction (one request can actually consist of multiple HTTP messages). Hooking into the Request Layer is challenging because it would probably require a significant refactoring.

So overall, this is just not easy to achieve...

@battre Thanks for the update.
I can understand the API for *all* requests won't be efficient and even possible.

But it might be a little bit easier to first release the API to some specific content types, such as javascript files.
These are usually quite small and loaded asynchronously.

I saw several use cases that js files should be altered before loaded, otherwise it would be useless even if I use a content script file to change its content later.
Firefox provides an API called onbeforescriptexecute that can achieve this target, but I didn't find anything similar on Chrome.

Thanks.

Do you need to modify the JS files or do you want to replace them? In the latter case, you might be able redirect the request to a data:// URL for example. See http://en.wikipedia.org/wiki/Data_URI_scheme

I don't know, whether this has security implications, though. (thinking for Content Security Policies) 

I meant modifying the content of js files.
It would usually be changing some improper variables or disable a popup in my case.

Currently it can already by done by redirecting the javascript link to a proxy server and modifying the content on the fly.
But it would be nicer to do it without the extra server.

And yes, I think security should be carefully considered, since I guess the proxy server method won't work if certain CSP is presented.
Maybe this API can be banned if CSP forbids remote scripts.

@battre Is it possible to get read access to a response body via the declarativeWebRequest or webRequest API?

The functionality does already exists, via the chrome.devtools.network API, but it's only exposed to devtools extensions.

See comment #19.

Assuming adding only read functionality for simplicity, I am still confused as to what the major roadblocks are for reading the response data through some file handle. Reading the responseHeaders from the onCompleted listener is already implemented. battre mentioned that it is a matter of when that data should be released and it would seem like this event listener would be ideal, or am I misunderstanding him?

I also would really like the ability to read the response body. Clearly the network tab has all the needed information - why can't the extension API plug into the same data source as the network tab?

Reading the existing response body would be very useful for me as well. It seems like the only way to do so is to listen for webRequest.onCompleted and generate a whole new duplicate request yourself. Doable, but not good.

I need this feature too :) At least for read-only.

With wireshark you can set limits on packet capture size.  An analogous limit on the captured response body size would allow many useful cases while preventing .iso's from chewing up resources.

waiting for this feature...

 Issue 346089  has been merged into this issue.

I'm going to work on supporting read-access of the response body.

Design document (read and write) is at https://docs.google.com/document/d/1iE6M-YSmPtMOsec7pR-ILWveQie8JQQXTm15JKEcUT8.

I need this feature too, response body is very useful for us.

modify response body is a nice feature for developers

Hi, any progress to report Rob? I checked your code review page and didn't notice anything relating to this bug.

@karir (#37)
I did not have the time to implement this feature. I hope to make some progress during the summer break.

My initial goal is to get read-only access; I might look into implementing write access in the future when the HTML5 Streams API is implemented ( issue 240603 ).

Great, even read only access would really open up possibilities for extension developers.

...Is there a good news? I'm also eagering for this feature to construct my extension. Thanks.

@Hakatasi,

I don't think this will ever be possible.
To much security issues!
Oh well...

Read-only access was approved at https://groups.google.com/a/chromium.org/d/msg/apps-dev/v176iCmRgSs/iM-72Evf8JgJ. Writable response bodies has not been discussed yet.

Please don't add "me too" or "when is it ready?" comments, because it will be mailed to each of the 100+ followers of this bug. When the draft of the implementation is ready, I will post a link here. If you have any questions or requests that are not relevant for everyone, just mail me privately, or comment on the design proposal document (c33).

Hi all, I just released a devtools extension that does just that. It's called tamper, it's based on mitmproxy and it allows you to see all requests made by the current tab, modify them and serve the modified version next time you refresh. It's a pretty early version but it should be compatible with OS X and Windows. Let me know if it doesn't work for you. You can get it here http://dutzi.github.io/tamper/ 

Hi all, since the last update in this issue was 5 months ago, and we are still waiting for the promised draft implementation link, I hope it's not a problem to ask "when is it ready?" Do you have any updates or news for us?

#44 There is no news. This issue is not high on my priority list at the moment.

Just to comment on dutzi's suggestion called Tamper, it seems users will need to do a bit more installation via command line, which makes it the bottom choice for my project. My current extension boasts a one-click install (since its competitors aren't) and I don't want to break that.

So I really hope this gets implemented even part-by-part, considering it's been half a year since read-only access was approved. Reading response body is the only thing my app needs, and with it, will solve much of my community's problems. I can't stress enough how great this will help.

Sadly, not implemented yet, I need this one, even a read only API.

Read-only access to the response body is being tracked at issue 487422.

As a developer I can see the appeal of being able to peek at the response let alone modifying it. That could open door to new possibilities for the extension devs.

As a user, I see this as a huge security risk. No extension should be allowed to access any of the communications, even in read only mode. I can live with extensions being able to see URLs of static resources requested by the page and blocking request completely, but only when the request is initiated. Any Ajax and form get/post comms shouldn't be available to any extension. I would consider Chrome an unsecure/unsafe browser.

#49 At the extension install, you explicitly agree to the following permission: "Read and change all your data on [url list]".

Without the user explicitly agreeing, an extension cannot access data being exchanged with specified URL patterns, read-only or not.

And even without webRequest, once a host or content script permission is granted, an extension can do powerful stuff anyway.

Read access to the response body +1, modification not necessary.

@#51: check #48 by rob (Read-only access to the response body is being tracked at issue 487422) you should probably +1 there ;)

One interesting venue to implement this is probably by using service workers in an extension (see https://code.google.com/p/chromium/issues/detail?id=501569). It would be interesting if an extension could register a service worker for different origins and then intercept and process requests. The question is what happens if the origin itself also registers a service worker? Then some stacking of service workers would be needed (extension probably coming first).

But from the performance and API viewpoint the best way is probably to reuse the service workers here.

>allow extension to edit response body

I am more than sure that you also need to add a possibility to change the headers, and even responce code!

Please allow extension to edit response body.

+1 for read and modify options on the response body.

+1 for me too. I need it desperately for our extension MyTrackingChoices
for chrome.

Hi guys,

maybe, if it's easier, we can just start with providing first only "read
access to http response body".

what do you think?

On Sat, Jan 16, 2016 at 11:19 PM, jagdish achara <jagdish.achara@gmail.com>
wrote:

@jagdish.achara@gmail.com For read-only, see
https://code.google.com/p/chromium/issues/detail?id=487422

++ read

I would love to see the ability to modify responses.

+1 modify responses

you can do this by redirecting to a data uri containing the desired result, but not if the request required a CORS pre-flight OPTIONS request that was not handled.

#63, It's not the same as modifying. You only redirect. So you don't get the same origin... Which means you don't get the same access to all client side storage like localStorage.

To me that's an issue

At least allow extension to read response body.

This might be solution to someone:

- create http proxy in chrome extension
- setup chrome proxy settings to forward all requests to the local proxy

This way you will intercept all requests and will be able to modify (or even simulate) all responses.

Working implementation: check "network record" extension and "network replay" app in the store. I had to create app because I had to access local file system.

@Comment 67 by o...@gordeev.cz – comments 43 and 46 already covered this solution, just scroll up...

Hi there,

"Network record" cannot work with Chrome 54 (at least 64 bit version)
Error: 

Failed to load resource: net::ERR_FILE_NOT_FOUND
_generated_background_page.html:1 Unchecked runtime.lastError while running notifications.create: Unable to download all specified images.
    at showAlert (chrome-extension://ihbkogfblhfbnompooimhejpkidoipcl/index.js:72:26)
    at onAttach (chrome-extension://ihbkogfblhfbnompooimhejpkidoipcl/index.js:86:9)
chrome-extension://ihbkogfblhfbnompooimhejpkidoipcl/icon1.png Failed to load resource: net::ERR_FILE_NOT_FOUND
_generated_background_page.html:1 Unchecked runtime.lastError while running notifications.create: Unable to download all specified images.
    at showAlert (chrome-extension://ihbkogfblhfbnompooimhejpkidoipcl/index.js:72:26)
    at onAttach (chrome-extension://ihbkogfblhfbnompooimhejpkidoipcl/index.js:86:9)

This is basic functionality. I wonder why it has lagged for 6 years without progress.

How else can a layer or cache or proxy between the UI and the browser be built then?

^

I suspect google is reluctant to add functionality that could be used maliciously.
This functionality could be used for ad-injection or password theft. It really would be nice to have for exactly the reasons you mentioned though.

Ad injection and password theft is already possible with content scripts.

@70:
It's normal standard practice for google to ignore vital bugs or functionality for years. Google just don't care about its users no matter what their pr bullshit department say.

Just recently they added a bot that hides bug reports that haven't been active for a while. Disgusting practice indeed.

The way I see it is to use click-bait and spam tactics for bug reports and public whining to get stuff done. Google do care about its image even though their 'Don't be evil' motto have been wiped under the rug for years.
If you want eyes on your bug report, file it as vital security bug and such. And file several duplicated bug reports under different accounts. And publish your bug reports and report how long it takes for google to do something. Make the whole process really public and be a bloodhound about it. Keep gnawing at the bone and irritate the chrome dev team publicly, constantly. Point out the developers that are responsible for fixing the bugs publicly. Give them bad reputation. Get under their skin about it.

Heck, Firefox with its issues is still better than chrome in many many many ways because it doesn't limit, block and restrict what you can do with it. Firefox treats you as an intelligent adult and not as a child. Too bad Firefox is humping the chrome bandwagon now. Open source is good when this happen. The name Firefox will soon be replaced with some fork name.

I might be censored and this comment deleted and even banned but I'll risk it.

Patches are welcome as Chromium is an open source project.

Unproductive comments that don’t move the issue forward are not.

I'm opening this bug up for external commenters again. Please only post comments if you intend to work on the implementation.

Those who are looking for the ability to edit response bodies of requests in a specific frame can consider using the DevTools API to intercept and rewrite responses. For more details, see https://bugs.chromium.org/p/chromium/issues/detail?id=487422#c29

Unlike Firefox's API (webRequest.filterResponseData, see https://crbug.com/487422#c20 ), the DevTools API is not a specific extension API, so although the functionality works, expect having to write quite some code to put the pieces together (or use a library).