“file uri scheme”

It seems that Safari on iOS is closer to the http redirection spec than the desktop safari. We use a 302 redirection in our load balancer that tells not to use the redirected URI for subsequent requests.Is this wanted ?EDIT: 302 or 301 redirection have the same problem, they don't use the redirected URI for subsequent requests

I am still consistently seeing this issue when I try to drag and drop a .cer file onto my simulators per the instructions in https://developer.apple.com/library/archive/qa/qa1948/_index.html. However, if I put my .cer file on a webserver an navigate to it using safari in the simulator, the profile installation process happens as expected.The drag and drop method tries to open the .cer file using the file:// scheme. The iOS 13 release notes do not specifically mention that loading a .cer file using the file:// scheme has been dropped, but they do mention changes to what file:// urls can do.https://developer.apple.com/documentation/ios_ipados_release_notes/ios_13_release_notes?preferredLanguage=occRemoved support for FTP and File URL schemes for Proxy Automatic Configuration (PAC). HTTP and HTTPS are the only supported URL schemes for PAC. This affects all PAC configurations including, but not limited to,

The documentation appears to be updated:The URL property must use an http, https, or file scheme. Custom app schemes are not supported. Additionally, the URL cannot be longer than 5,000 characters.

Hi,We are trying to port our Cordova app to WKWebView. But the Cordova File plug-in use a custom scheme to work. With UIWebView, this plug-in was intercepting URLs with custom scheme using NSURLProtocol to load related files (local resources files). It seem that it is not possible to do that with WKWebView, and it is a blocker for us. There is another strategy to do that in WKWebView?Do we need to wait iOS 11 to have this kind of feature?Thanks!

This is contains the html describing the build scheme. It should only change when you change the scheme. Another file contains breakpoints, no use to source control. AFAIU, it should be safe to ignore all in your account (igorkorot) userData.

Hey,Here are the details of the work around that I used to fix this (for me)/** In the Safari Sample App **/function extractContentId(data) { myContentId = arrayToString(data); console.log('AssetID : ' + myContentId); // contentId is passed up as a URI, from which the host must be extracted: - Karl: Bug in Safari if URI is longer that 16 chars var link = document.createElement('a'); var uri = encodeURIComponent(myContentId); link.href = myContentId; //return link.hostname; console.log('AssetId :' + myContentId.split('//')[1]); return myContentId.split('//')[1]; //Karl: work around for bug }/** Parsing AssetId in C# **/System.Text.Encoding.ASCII.GetString(bytes);

Also: the same issue exists for scheme files, which is equally annoying.