Open JohnRiv opened 2 years ago
JohnRiv
commented
2 years ago 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
commented
2 years ago 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.
Requests/responses sharing and proxy between Native and WebView
John Riviello, Jiasheng Wu
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:
Note: the open questions on handling CORS & whether we should distinguish access between 1P and 3P content needs to be further considered.
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
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.
N/A
N/A
Token-LiMing
commented
2 years ago 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:
- 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 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
commented
2 years ago 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
commented
2 years ago Thanks for that write up to merge them. I'd like to add this scenario:
Updated. https://github.com/WebView-CG/usage-and-challenges/issues/12#issuecomment-1138115981
Token-LiMing
commented
2 years ago 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:
- 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.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组织的提案更倾向于以能力的方式行文，通过能力提供完成不同功能，故比较建议的行文如下：
Optional network proxy capability in WebView
John Riviello, Jiasheng Wu
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.
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
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.
QingAn
commented
2 years ago Trying to merge the content. The latest update is https://github.com/WebView-CG/usage-and-challenges/issues/12#issuecomment-1138115981
QingAn
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago 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 https://github.com/WebView-CG/usage-and-challenges/issues/12#issuecomment-1138115981
Please take a look whether it works for you.
rayankans
commented
2 years ago Thank you @QingAn, looks good to me
QingAn
commented
2 years ago @JohnRiv Please also take a look at the latest version. https://github.com/WebView-CG/usage-and-challenges/issues/12#issuecomment-1138115981
If works for you, I will create a PR to merge it to the use case document.
JohnRiv
commented
2 years ago Looks good to me, please create a PR @QingAn. Thank you!
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