Preflight and HTTPS problem

Question

DMTSupport OP

Created Sep ’18

Replies 4

Boosts 0

Views 7.5k

Participants 4

Hi everybody,

we are encoutering a problem using WKWebview in our app when calling our rest services.

We are unable to call our HTTPS domain due to "Preflight fails". We are in cross-origin context, so we have added all required Headers, in fact all was working fine till ios 12 (we are using beta 8).

Safari shows in console:

[Error] Preflight response is not successful

[Error] XMLHttpRequest cannot load https://xxxxxxxxxxxx due to access control checks.

So the OPTIONS calls is failing, even if all the headers (allow-origin etc....) are availables server-side.

Additional informations:

- if we change rest URL to HTTP, all works fine in ios12

- if we use previous version of iOS (9,10,11) all works fine and OPTIONS and GET/POST methods are correclty managed

- we do not use self signed certificates for web services domain

- if we open the same AJAX Rest service Url in Safari (so using GET method) all works fine and no certificates errors are prompt

- the only error that - maybe - could help looking deeply on device log is the following:

Task <1DB0CC48-1C9E-4EDA-BF3A-25D58BAAD09D>.<50> completed with error Error Domain=NSURLErrorDomain Code=-999 UserInfo={NSErrorFailingURLStringKey=<private>, NSErrorFailingURLKey=<private>, _NSURLErrorRelatedURLSessionTaskErrorKey=<private>, _NSURLErrorFailingURLSessionTaskErrorKey=<private>, NSLocalizedDescription=<private>} [-999]

Seems to be something related to the domain, but it is very strange because trying to open the same URL using Safari the service returns data correctly (from the same ios12 device).

Any helps?

Thank you!

Marco

Boost

Answer 1

cultienski OP

Sep ’18

Hello! Am I having the same problem, any news on the case?

Wait! Thank you!

1

Answer 2

vincenzo-lba OP

Aug ’20

Any news about this??

1

Answer 3

hawkes OP

Sep ’20

Are there any links about this being worked?

To duplicate the issue:

Go to site (https : //) cidilabs.instructure.com/courses/3/pages/upload-slash-embed-image-test
Then refresh that page to see the broken image link.

Workarounds:

Always open a private browser when going to a CORS redirect image page. The issue only happens when the image is cached.
Add a terminating solidus (forward slash) to all image src links that are cached CORS redirect paths. The issue only happens when the redirect path looks like a file not a directory.
Make the image src URL a DIFFERENT host than the page it's embedded in. The issue only happens if the cached image src redirect URL is the *same* host as the web page.
Use FireFox or Chrome when going to a page with a CORS image src redirect. The issue only happens with Safari.

0

Answer 4

hawkes OP

Oct ’21

Any thoughts on this issue? I see posts that Safari might be ignoring the Cache-Control headers when there is a Vary header present and doing the OPTIONS PREFLIGHT request. Especially for an image content-type. Is that possible? Firefox and Chrome do not have the issue. They do not do the OPTIONS PREFLIGHT on this response, they keep doing the GET request for this image. Is there some other parameter Safari needs to prevent it from doing the PREFLIGHT for a no-cache image?

Redirect Response
302
Pragma: no-cache
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate
Vary: Accept-Encoding
Content-Type: image/png

0