shouldInterceptRequest after http redirection

[Pavel Zdeněk]

Hi all,

i am trying to completely observe and possibly manipulate a WebView traffic. For potential other amphibious devs here, getting as close to iOS NSURLProtocol as possible. So i hooked on WebViewClient.shouldInterceptRequest and started with just logging and returning null to everything - which "will continue to load the resource as usual". I am getting all resource loads, images, stylesheets, subframes this way, EXCEPT when a request is a redirection. 302 specifically in my testing case, but other kinds of redirects would behave the same i believe. shouldInterceptRequest is never called with the actual redirection target. So i could not even know where it redirected to. I can, because onPageStarted is called as expected - only it's read-only void event handler, obviously incapable of what i would like to do in shouldInterceptRequest.

Pseudo event log if URL "A" gives plain 200 response:

1. shouldIntercept A

2. server: A -> 200

3. onPageStarted A

if URL "A" redirects to "B" which responds normally

1. shouldIntercept A

2. server: A -> 302

3. onPageStarted A

4. server: B -> 200

5. onPageStarted B

shouldIntercept for B is missing. It looks like returning null in shouldInterceptRequest means giving up control over the whole http stream (until closed), not just the one request which it originally was called with and replied to.

Can someone confirm this? Is it by design or can it be considered a bug?

Regards,

Pavel

[Selim Gurun]

ShouldInterceptRequest never supported observing and monitoring all webview traffic, i.e. websockets and serviceworkers are two examples I think. 

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.
To post to this group, send email to android-w...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/2ec93741-1f48-427e-8057-9d4d618db2c4%40chromium.org.

[Pavel Zdeněk]

Ok “completely observe” was a misleading overstatement, sorry. I would be just fine with following plain DOM resources. But even a simple redirected main frame is not observable at the moment.

[Torne (Richard Coles)]

We're aware of this limitation and we're planning to have support for intercepting more requests in future, though this might require a new API as changing the behaviour of the existing API is probably going to break apps that don't expect to see those requests :/

We don't have an ETA for this, and if it needs a new API it will have to wait for a new Android version as we can't add APIs for existing platform releases.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/DFD063C4-7BCE-4D0F-A849-64924AD8CD26%40gmail.com.

[Pavel Zdeněk]

Thanks for the authoritative answer, even if not a favourable one. So is it a Chromium deficit, or just Android binding deficit? I am trying to comprehend the likeliness of this functional addition. I speculate that down on the WebKit/Blink level, everything is/should be possible as is on iOS ever since v2.0.

[Torne (Richard Coles)]

I'm not 100% sure of the history here because it was a while ago but I think we intentionally made it work this way to emulate the behaviour of the old WebView. It shouldn't be difficult to get to this information in the chromium network stack, but because it's a behavioural change we have to be careful about how we expose it to applications.

[Chen Zhixiang]

I'm very shocked to hear this.

We are building adblocker mechanism on our customed android chromium webview based browser using extactly the shouldInterceptRequest API.

If shouldInterceptRequest can not intercept all the outgoing network url request, then there is a bad hole here.

On Wednesday, April 6, 2016 at 1:05:23 AM UTC+8, Selim Gurun wrote:

ShouldInterceptRequest never supported observing and monitoring all webview traffic, i.e. websockets and serviceworkers are two examples I think. 

On Tue, Apr 5, 2016 at 9:19 AM, Pavel Zdeněk <pavel....@gmail.com> wrote:

Hi all,

i am trying to completely observe and possibly manipulate a WebView traffic. For potential other amphibious devs here, getting as close to iOS NSURLProtocol as possible. So i hooked on WebViewClient.shouldInterceptRequest and started with just logging and returning null to everything - which "will continue to load the resource as usual". I am getting all resource loads, images, stylesheets, subframes this way, EXCEPT when a request is a redirection. 302 specifically in my testing case, but other kinds of redirects would behave the same i believe. shouldInterceptRequest is never called with the actual redirection target. So i could not even know where it redirected to. I can, because onPageStarted is called as expected - only it's read-only void event handler, obviously incapable of what i would like to do in shouldInterceptRequest.

Pseudo event log if URL "A" gives plain 200 response:

1. shouldIntercept A

2. server: A -> 200

3. onPageStarted A

if URL "A" redirects to "B" which responds normally

1. shouldIntercept A

2. server: A -> 302

3. onPageStarted A

4. server: B -> 200

5. onPageStarted B

shouldIntercept for B is missing. It looks like returning null in shouldInterceptRequest means giving up control over the whole http stream (until closed), not just the one request which it originally was called with and replied to.

Can someone confirm this? Is it by design or can it be considered a bug?

Regards,

Pavel

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-webview-dev+unsub...@chromium.org.

[Torne (Richard Coles)]

shouldInterceptRequest was primarily intended for offline caching or separate-network-stack use cases where the app already has a copy of the resource requested and is simply providing it directly to webview without webview having to access the network itself.

There's no real way to block a request using shouldInterceptRequest. People do it by returning empty/dummy/fake resources, but that's not actually blocking the request from chromium's POV.

To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.

To post to this group, send email to android-w...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/2ec93741-1f48-427e-8057-9d4d618db2c4%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "android-webview-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.

To post to this group, send email to android-w...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/4cec0d41-1206-4856-9c3a-f074fd6a8dc4%40chromium.org.