Properly escaped character disables valid itms-services download
| Originator: | alexzavatone | ||
| Number: | rdar://13006890 | Date Originated: | 14-Jan-2013 10:05 AM |
| Status: | open | Resolved: | |
| Product: | itms-services | Product Version: | unknown |
| Classification: | Reproducible: | Yes |
14-Jan-2013 10:05 AM Alex Zavatone: Summary: Creating an Enterprise installation of an iOS app using OTA and a manifest link within a web page. Within the url parameter, even if the space character is properly escaped with a %20, if there is a space anywhere in a folder name or file name to in the path to the manifest pList used as the , itms-services://?action=download-manifest will fail without reporting an error. Steps to Reproduce: Prepare a valid iOS ipa and manifest file for enterprise distribution and place them on an http server that is configured to install IPA files through OTA distribution. Verify that the manifest plist file loads in a browser on a Mac. Duplicate this file and add a space in the filename of the pList or the folder holding it. Create an HTML file that includes links to both manifests. Make sure to escape out the space character with %20 Examples: The link below will work itms-services://?action=download-manifest&url=http://mydomain.com/test/myApp.plist" The link below will fail itms-services://?action=download-manifest&url=http://mydomain.com/sample%20app%20test/myApp.plist" Expected Results: Both links should trigger the app install, but the itms-services link where the url has a space in it will not. Actual Results: The link with the properly escaped %20 character fails to issue a download of the manifest pList without issuing a warning. Regression: Notes: Escaping out other characters works fine (A and C tested). The url value within the manifest file CAN have a space in it with no problem. Only when this validly escaped is in the url parameter of the itms-services://?action=download-manifest&url= does this fail. From the discussion on the Xcode Users list FYI, if anyone else is interested in this itms-services related question: From: http://blog.appliedis.com/2012/10/29/wireless-distribution-of-enterprise-ios-apps/ 5) There is apparently a bug in Apple’s implementation of the “itms-services” protocol. No spaces, even if they are escaped or URL Encoded, are allowed in the file name or web folder structure. Even if the space character is properly escaped with a %20, if there is a space anywhere in a folder name or file name to in the path to the manifest pList used as the , itms-services://?action=download-manifest will fail. Examples: The link below will work itms-services://?action=download-manifest&url=http://mydomain.com/test/myApp.plist" The links below will fail itms-services://?action=download-manifest&url=http://mydomain.com/sample%20app%20test/myApp.plist" itms-services://?action=download-manifest&url=http://mydomain.com/sample+app+test/myApp.plist" However, If there is a space within the url key value of the ipa within the manifest pList the app install works just fine. It doesn't have to be escaped to work. But if the itms-services doesn't even support a validly escaped space character and no error is reported in this case. What this all means is that you can't freely put a bunch of folders for your ipa files with nicely descriptive names on an http server and expect them all to work for install. Certainly sucks more than it needs to. On Jan 8, 2013, at 2:58 PM, Alex Zavatone wrote: Further testing indicates that any space character anywhere in the path of the URL of an ipa will prevent OTA installation using itms-services:// from triggering an iOS app install. You can not escape out the space char with %20. Other characters like the standard alphanumerics can be escaped out without a problem. Even if the path to the ipa will resolve in a browser, itms-services will not load the plist file. Is there any reference anywhere that explains why this would fail in itms-services? TIA Sent from my iPad
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!