New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 104058 link

Starred by 414 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 487422

Blocking:
issue 91189


Show other hotlists

Hotlists containing this issue:
Hotlist-1
Hotlist-1


Sign in to add a comment

WebRequest API: allow extension to edit response body

Reported by david7...@gmail.com, Nov 13 2011

Issue description

Chrome Version       : 17.0.932.0
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

Hi! I was trying to make a code coverage in scripts file using WebRequest. I tried to make in all methods that I can throught. The problem is that is impossible edit script in runtime currently. No exists API support for it.

My suggestion is basically make a BlockResponse like "content", that can to be run onBeforeRequest and onBeforeSendHeaders.

It will be very useful for make my Code Coverage extension. I need intercept the script content and edit this script to a new content (that add code coverage structure).

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.932.0 Safari/535.8


 
Cc: mpcomplete@chromium.org battre@chromium.org
Labels: -Area-Undefined Feature-Extensions OS-All
Do you want to modify the data that is coming over the wire? It would have to be after onBeforeSendHeaders. 

Comment 2 by david7...@gmail.com, Nov 18 2011

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;
Labels: -Type-Bug -OS-Windows Type-Feature
Summary: WebRequest API: allow extension to edit response body
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.

Comment 4 by david7...@gmail.com, Nov 18 2011

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...
Status: Available
(Marking as Available to get out of triage queue - not necessarily as an indication that we will implement the feature)

Comment 6 by adman....@gmail.com, Dec 13 2011

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.
Blocking: 91189

Comment 10 by Deleted ...@, Nov 30 2012

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

Comment 11 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Feature-Extensions Cr-Platform-Extensions
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!

Comment 14 by Deleted ...@, Jun 2 2013

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!

Comment 15 by h0x...@gmail.com, Jun 4 2013

Any news?
I'm also waiting for this feature!

Comment 17 by Deleted ...@, Jun 11 2013

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

Comment 18 by Deleted ...@, Jun 11 2013

I'd also find this feature quite useful
Cc: vabr@chromium.org jyasskin@chromium.org
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...

Comment 20 by zhub...@gmail.com, Jun 12 2013

@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) 

Comment 22 by zhub...@gmail.com, Jun 12 2013

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.

Comment 23 by robwu...@gmail.com, Jul 17 2013

@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.

Comment 25 by franz...@gmail.com, Jul 31 2013

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.

Comment 28 by Deleted ...@, Oct 24 2013

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

Comment 29 by rms...@hotmail.com, Jan 20 2014

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.

Comment 30 by Deleted ...@, Feb 25 2014

waiting for this feature...
 Issue 346089  has been merged into this issue.
Cc: bol...@chromium.org

Comment 33 by rob@robwu.nl, Mar 18 2014

Owner: rob@robwu.nl
Status: Started
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.

Comment 34 Deleted

Comment 35 by Deleted ...@, May 16 2014

I need this feature too, response body is very useful for us.
modify response body is a nice feature for developers

Comment 37 by karl...@gmail.com, Jun 24 2014

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

Comment 38 by rob@robwu.nl, Jun 24 2014

Status: Assigned
@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 ).

Comment 39 by karl...@gmail.com, Jun 24 2014

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...

Comment 42 by rob@robwu.nl, Sep 12 2014

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).

Comment 43 by dutz...@gmail.com, Oct 6 2014

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?

Comment 45 by rob@robwu.nl, Feb 18 2015

#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.

Comment 47 by Deleted ...@, Apr 22 2015

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

Comment 48 by rob@robwu.nl, May 31 2015

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

Comment 49 by patr...@pulka.eu, Sep 4 2015

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.

Comment 51 by keyna...@gmail.com, Sep 20 2015

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 ;)

Comment 53 by mmi...@gmail.com, Dec 8 2015

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:
++ read

Comment 61 by vabr@chromium.org, Jan 26 2016

Cc: -vabr@chromium.org

Comment 62 by ppmitra@google.com, Jan 29 2016

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.

Comment 64 by ji...@warting.se, Feb 15 2016

#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
Cc: -mpcomplete@chromium.org

Comment 66 by siam9...@gmail.com, Aug 10 2016

At least allow extension to read response body.

Comment 67 by o...@gordeev.cz, Sep 3 2016

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)

Comment 70 by pacer...@gmail.com, Feb 22 2017

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?

Comment 71 by keyna...@gmail.com, Feb 23 2017

^

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.
Labels: Restrict-AddIssueComment-EditIssue
Patches are welcome as Chromium is an open source project.

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

Comment 75 by rob@robwu.nl, Feb 21 2018

Labels: -Restrict-AddIssueComment-EditIssue
Owner: ----
Status: Available (was: Assigned)
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).

Sign in to add a comment