Sharing HTTP requests/responses between Native & Webview

[JohnRiv]

Sharing HTTP requests/responses between Native & Webview

Follow up to a separate but related topic in Issue #9

Submitter(s)

John Riviello

Motivation

In a hybrid Native/Webview app, the native app and the webview may make the exact same HTTP calls to talk to an API. A way to share those HTTP requests/responses between Native & Webview would be useful. I think an ideal case is specifying specific URLs that can be shared (with flexibility similar to proxy software) and then when the webview or Native makes an HTTP request that matches one of those URL patterns, the response can be shared by Native and Webview if either makes a subsequent request that the HTTP caching rules would result in the cached version being returned.

Stakeholders

WebView provider: Apple, Google, deciders on how to enhance sharing between WebView & Native
End user: users of the App save bandwidth by not having to make duplicate calls

Analysis

In talking to iOS & Android native application developers, if this is currently even possible in some way, it is not a recommended pattern. So making this a standard that is easy to use for both Native and WebView developers would be a win for both groups.

Related W3C deliverables and/or work items

TBD

[JohnRiv]

Brady Duga brought up an EPUB use case regarding #9 that could apply here where it can be useful to download an EPUB file natively without ever launching a Webview to download it, but then make that downloaded file available to a Webview.

[QingAn]

As discussed during the call, #9 and this issue are targeting the same use case of requests/responses sharing between Native & WebView. Here, I am trying to merge them. @JohnRiv @Token-LiMing Please take a look whether it capture your intention.

Use case name

Requests/responses sharing and proxy between Native and WebView

Submitter(s)

John Riviello, Jiasheng Wu

Motivation

In a hybrid Native/WebView app, some Native app may load first-party website or third-party website through WebView. So, the Native app and the WebView may make the exact same calls in first-party business, or Native app handles the resource request on behalf of WebView and the corresponding response data returned to WebView can even be different with what is received by Native from the backend server. Also, not all requests want to be proxied through Native, WebView user want to proxy a small number of requests locally to load offline resources.

Some scenarios:

1. Document access control: it is expected to manage the access control of Web access documents, allowing different users to access documents of different levels.
2. Security firewall: In order to meet compliance requirements, network engineers want to audit requests within the app, and do not allow insecure requests to be sent on the web.
3. Transcoder: In special scenarios, we may need to convert GIF images to JPEG images to send to reduce traffic, and may also need to translate documents to meet communication needs in different language scenarios. For example, it's hard for a user to communicating in English. When communicating, the user can type Chinese and it will be automatically translated into English.
4. Anonymous: Some users may have higher requirements for the privacy of Web access, requiring that requests within the Web must remove identity features (such as client IP address, From header, Referer header, cookie, URI session ID), providing a high degree of privacy and anonymity.
5. Reducing network requests: A hybrid app (in the sense that some screens are native code and other screens are Webviews) may make some of the same network requests (HTTP GET, POST, PUT, DELETE, or other network connections supported by webviews such as Web Sockets and WebRTC) in both the native screens and the webview screens. Being able to easily share those responses between native and web (while maintaining proper HTTP cache semantics) would reduce redundant requests, saving end-users bandwidth and reducing server traffic.

Note: the open questions on handling CORS & whether we should distinguish access between 1P and 3P content needs to be further considered.

Stakeholders

WebView provider: Apple, Google, deciders on how to enhance sharing between WebView & Native
WebView user: Native Business rely on WebView to send internal request, or load offline resource
End user: users of the App save bandwidth by not having to make duplicate calls

Analysis

This is currently even possible in some way, but it is not a recommended pattern. So making this a standard that is easy to use for both Native and WebView developers would be a win for both groups.
shouldInterceptRequest in Android WebView provide develop with optional network interception capability.

Related W3C deliverables and/or work items

N/A

How is the issue solved in the Browser, and what’s more is needed?

N/A

[Token-LiMing]

As discussed during the call, #9 and this issue are targeting the same use case of requests/responses sharing between Native & WebView. Here, I am trying to merge them. @JohnRiv @Token-LiMing Please take a look whether it capture your intention.

Use case name

Requests/responses sharing between Native and WebView

Submitter(s)

John Riviello, Jiangsheng Wu

Motivation

In a hybrid Native/WebView app, some Native app may load first-party website or third-party website through WebView. So, the Native app and the WebView may make the exact same calls, or Native app handles the resource request on behalf of WebView and the corresponding response data returned to WebView can even be different with what is received by Native from the backend server. Some scenarios:

1. Document access control: it is expected to manage the access control of Web access documents, allowing different users to access documents of different levels.
2. Security firewall: In order to meet compliance requirements, network engineers want to audit requests within the app, and do not allow insecure requests to be sent on the web.
3. Transcoder: In special scenarios, we may need to convert GIF images to JPEG images to send to reduce traffic, and may also need to translate documents to meet communication needs in different language scenarios. For example, is's hard for me to communicating with English, when communicating, type Chinese, and send it out and hope that it will be automatically translated into English.
4. Anonymous: Some users may have higher requirements for the privacy of Web access, requiring that requests within the Web must remove identity features (such as client IP address, From header, Referer header, cookie, URI session ID), providing a high degree of privacy and anonymity.

Stakeholders

WebView provider: Apple, Google, deciders on how to enhance sharing between WebView & Native WebView user: Native Business rely on WebView to send internal request, or load offline resource End user: users of the App save bandwidth by not having to make duplicate calls

Analysis

This is currently even possible in some way, but it is not a recommended pattern. So making this a standard that is easy to use for both Native and WebView developers would be a win for both groups. shouldInterceptRequest in Android WebView provide develop with optional network interception capability.

Related W3C deliverables and/or work items

TBD

How is the issue solved in the Browser, and what’s more is needed?

TBD

整体思路方向一致，但是中心核心略有不同。

可选网络拦截更偏向于给Native提供WebView内网络请求的代理能力，属于能力提供，并且有明确的主从关系，Native是使用方，WebView是提供方。基于此能力，可以用于请求的共享。

参考操作系统中的HTTP代理，是系统给使用方暴露的能力，可以基于此能力做请求共享等操作。

若以可选代理为主题，共享请求为重要使用场景行文更贴切主题。

备注：英文名应该是 Jiasheng Wu

[JohnRiv]

Thanks for that write up to merge them. I'd like to add this scenario:

Reducing network requests: A hybrid app (in the sense that some screens are native code and other screens are Webviews) may make some of the same network requests (HTTP GET, POST, PUT, DELETE, or other network connections supported by webviews such as Web Sockets and WebRTC) in both the native screens and the webview screens. Being able to easily share those responses between native and web (while maintaining proper HTTP cache semantics) would reduce redundant requests, saving end-users bandwidth and reducing server traffic.

[QingAn]

Thanks for that write up to merge them. I'd like to add this scenario:

Updated. #12 (comment)

[Token-LiMing]

As discussed during the call, #9 and this issue are targeting the same use case of requests/responses sharing between Native & WebView. Here, I am trying to merge them. @JohnRiv @Token-LiMing Please take a look whether it capture your intention.

Use case name

Requests/responses sharing between Native and WebView

Submitter(s)

John Riviello, Jiasheng Wu

Motivation

In a hybrid Native/WebView app, some Native app may load first-party website or third-party website through WebView. So, the Native app and the WebView may make the exact same calls, or Native app handles the resource request on behalf of WebView and the corresponding response data returned to WebView can even be different with what is received by Native from the backend server. Some scenarios:

1. Document access control: it is expected to manage the access control of Web access documents, allowing different users to access documents of different levels.
2. Security firewall: In order to meet compliance requirements, network engineers want to audit requests within the app, and do not allow insecure requests to be sent on the web.
3. Transcoder: In special scenarios, we may need to convert GIF images to JPEG images to send to reduce traffic, and may also need to translate documents to meet communication needs in different language scenarios. For example, is's hard for me to communicating with English, when communicating, type Chinese, and send it out and hope that it will be automatically translated into English.
4. Anonymous: Some users may have higher requirements for the privacy of Web access, requiring that requests within the Web must remove identity features (such as client IP address, From header, Referer header, cookie, URI session ID), providing a high degree of privacy and anonymity.5.
5. Reducing network requests: A hybrid app (in the sense that some screens are native code and other screens are Webviews) may make some of the same network requests (HTTP GET, POST, PUT, DELETE, or other network connections supported by webviews such as Web Sockets and WebRTC) in both the native screens and the webview screens. Being able to easily share those responses between native and web (while maintaining proper HTTP cache semantics) would reduce redundant requests, saving end-users bandwidth and reducing server traffic.

Stakeholders

WebView provider: Apple, Google, deciders on how to enhance sharing between WebView & Native WebView user: Native Business rely on WebView to send internal request, or load offline resource End user: users of the App save bandwidth by not having to make duplicate calls

Analysis

This is currently even possible in some way, but it is not a recommended pattern. So making this a standard that is easy to use for both Native and WebView developers would be a win for both groups. shouldInterceptRequest in Android WebView provide develop with optional network interception capability.

Related W3C deliverables and/or work items

TBD

How is the issue solved in the Browser, and what’s more is needed?

TBD

经过线下讨论，native通常是作为webview的消费方，能力建议是webview提供到native，网络代理能力也建议是单向代理，而非双向同步。
提交至w3c组织的提案更倾向于以能力的方式行文，通过能力提供完成不同功能，故比较建议的行文如下：

Use case name

Optional network proxy capability in WebView

Submitter(s)

John Riviello, Jiasheng Wu

Motivation

In a hybrid Native/WebView app, some Native app may load first-party website or third-party website through WebView. So, the Native app and the WebView may make the exact same calls in first-party business, or Native app handles the resource request on behalf of WebView and the corresponding response data returned to WebView can even be different with what is received by Native from the backend server. At the same time, not all requests want to be proxied through native code, webview user want to proxy a small number of requests locally to load offline resources. Some scenarios:

Document access control: it is expected to manage the access control of Web access documents, allowing different users to access documents of different levels.
Security firewall: In order to meet compliance requirements, network engineers want to audit requests within the app, and do not allow insecure requests to be sent on the web.
Transcoder: In special scenarios, we may need to convert GIF images to JPEG images to send to reduce traffic, and may also need to translate documents to meet communication needs in different language scenarios. For example, is's hard for me to communicating with English, when communicating, type Chinese, and send it out and hope that it will be automatically translated into English.
Anonymous: Some users may have higher requirements for the privacy of Web access, requiring that requests within the Web must remove identity features (such as client IP address, From header, Referer header, cookie, URI session ID), providing a high degree of privacy and anonymity.

Stakeholders

WebView provider: Apple, Google, deciders on how to enhance network proxy between WebView & Native
WebView user: Native Business rely on WebView to send internal request, or load offline resource
End user: users of the App save bandwidth by not having to make duplicate calls

Analysis

This is currently even possible in some way, but it is not a recommended pattern. So making this a standard that is easy to use for both Native and WebView developers would be a win for both groups.
shouldInterceptRequest in Android WebView provide develop with optional network proxy capability.

Related W3C deliverables and/or work items

How is the issue solved in the Browser, and what’s more is needed?

[QingAn]

Trying to merge the content. The latest update is #12 (comment)

[QingAn]

@rayankans after you adds some note on the security and privacy consideration, I will create a PR to put this use case to our WebView: Usage Scenarios and Challenges document

[rayankans]

I don't have an answer for this, so I would suggest having open questions on handling CORS & whether we should distinguish access between 1P and 3P content.

[QingAn]

I don't have an answer for this, so I would suggest having open questions on handling CORS & whether we should distinguish access between 1P and 3P content.

I add a note #12 (comment)

Please take a look whether it works for you.

[rayankans]

Thank you @QingAn, looks good to me

[QingAn]

@JohnRiv Please also take a look at the latest version. #12 (comment)

If works for you, I will create a PR to merge it to the use case document.

[JohnRiv]

Looks good to me, please create a PR @QingAn. Thank you!