Chrome iOS makes two requests when trying to download an Apple Wallet .pkpass file
Reported by
jcl...@campuslabs.com,
Oct 13 2017
|
|||||||||||
Issue descriptionExample URL: Steps to reproduce the problem: 1. I'll attach a sample - basically set up a link to download an apple .pkpass file and make sure the response includes the appropriate content type 2. Tap on the link to download the file, note that the browser will make two requests when trying to download the file. 3. In this case with a static pkpass file, the request will work and you'll be prompted to add the pass to your Wallet. However, in a case where a web app may be generating the file dynamically, the second request does NOT include the headers/cookies of the original, so the second request will fail and you'll see the "Unable to download Pass at this time" warning What is the expected behavior? Ideally, the browser shouldn't be making the second request. The code works fine in both Safari and Firefox on iOS. Or if it has to make the second request for reasons, then it should be sure to send the same headers/cookies as the original request. There was a similar issue at some point with downloading pdf files: https://bugs.chromium.org/p/chromium/issues/detail?id=587709 What went wrong? in Chrome iOS, the app for some reason makes a second request when it receives a download response of a .pkpass file The second request does not include the same info as the original request. For static files, this is not an issue. However, in our case, we're dynamically generating the pass and returning it. Because the second request loses the header/cookie data, we lose information that's used in generating the pass and the second request fails. So what we see is that the first request appears to generate the file and return the file successfully, then Chrome creates a second request that doesn't pass session data, and our system (.net core app) fails on the second request. If the app only processed the request once, like Safari on iOS, then we would not have this issue. I'll attach a simple php example that could be run in order to demonstrate the two requests. Did this work before? N/A Chrome version: 61.0.3163.73 Channel: stable OS Version: iOS 11 Flash Version:
,
Oct 19 2017
,
Oct 19 2017
Seems related to cookies issue.
,
Oct 19 2017
This is not related to cookies issue. Chrome performs 2 requests because of WKWebView API constraints. This is how WKWebView API works for Chrome: - Chrome starts loading a passkit URL (request #1) - WKWebView sends decidePolicyForNavigationResponse: callback - Chrome verifies that mime type is passkit and can not be displayed in WKWebView - Chrome starts download of passkit file in order to add the file to Apple Wallet (request #2) We filed radar and WebKit bug to add new WKWebView API to allow downloading file with a single request: https://bugs.webkit.org/show_bug.cgi?id=158801
,
Nov 2 2017
,
Feb 6 2018
,
Feb 6 2018
jclark@, which headers are missing in the second request. We can't perform the download with a single request, but we can add cookies and missing headers to the second request. Thanks!
,
Feb 6 2018
There's a cookie .AspNetCore.Cookies that's included in the first request but not in the second. If I trace the calls in Charles, what I see is two separate calls. One appears to succeed and has the apple pass in the response. The second returns a 302, but it doesn't contain the cookie data that the original request contains. What I think happens is what is described in Comment #4 above. The first call goes through decidePolicyForNavigationResponse. Then a second request is made? But, because the second request didn't copy the cookie over, the second request fails and triggers the pass error. I think if you tell set decisionHandler(.cancel) I think the logic may drop into the didFailProvisionalNavigation method of the delegate? It may simply be that you manually duplicate the request in the policyHandler, you need to copy the cookies into the new request. If it would help, drop me an email at jclark@campuslabs.com and I can see if we can create a test account for you to use. I can provide you instructions on how to authenticate into our web app and then get to the screen that downloads the pass. That way you could try to debug the code.
,
Feb 7 2018
Thank you for updating the bug. If it's just a missing cookie issue, then we working on the fix. Prior to iOS 11 there was no API to get cookie from WKWebView, but now we can address the problem. The original request headers can also be passed from decidePolicyForNavigationAction to decidePolicyForNavigationResponse (where the download will be initiated), but it will take us a while to properly pipe the headers, this is why I asked if there is a specific header which you expect on the server side.
,
May 4 2018
PassKit download now sends cookie.
,
May 11 2018
Verified that the fix has solved our issue. Thanks!
,
May 11 2018
Thank you for confirming that! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by mge...@chromium.org
, Oct 13 2017