ios - WKWebView does not process "Set-Cookie" header correctly -

i use wkwebview in project implement web-based authorisation ui. use [nshttpcookiestorage sharedhttpcookiestorage] keep user session cookies of whole app , keep user authenticated in case of wkwebview redirects our backend pages.

the problem looks wkwebview ignores "set-cookie" header other domains in case. example:

initial request setup authentication process:

get /api2/providers/misfit/start/ http/1.1 host: api.welltory.com accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-encoding: gzip, deflate connection: keep-alive proxy-connection: keep-alive cookie: csrftoken=haf3px9l6vb9drtjtneqvsjsaimztync;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau user-agent: mozilla/5.0 (macintosh; intel mac os x 10_11_5) applewebkit/601.6.17 (khtml, gecko) version/9.1.1 safari/601.6.17 x-csrftoken: haf3px9l6vb9drtjtneqvsjsaimztync referer: https://api.welltory.com/api2/api/version/ accept-language: ru 

the result of request redirect target service login page, have request listed below:

get /auth/dialog/authorize?scope=public+birthday+email+tracking+session+sleeps&state=ndhvfdpcctfjckuebgnoj0e4s8pnw6wv&client_id=zkwjzk9qvaekzl4m&response_type=code&redirect_uri=https%3a%2f%2fapi.welltory.com%2fapi2%2fproviders%2fmisfit%2ffinish%2f%3fredirect_state%3dndhvfdpcctfjckuebgnoj0e4s8pnw6wv http/1.1 host: api.misfitwearables.com accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 x-csrftoken: haf3px9l6vb9drtjtneqvsjsaimztync connection: keep-alive proxy-connection: keep-alive cookie: csrftoken=haf3px9l6vb9drtjtneqvsjsaimztync;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau user-agent: mozilla/5.0 (macintosh; intel mac os x 10_11_5) applewebkit/601.6.17 (khtml, gecko) version/9.1.1 safari/601.6.17 accept-language: ru referer: https://api.welltory.com/api2/api/version/ accept-encoding: gzip, deflate  http/1.1 302 moved temporarily content-type: text/html; charset=utf-8 date: tue, 19 jul 2016 11:15:01 gmt location: /auth/login set-cookie: connect.sid=s%3arocf81hpxnkajbr1z3s4mi8e.5nm4jigw3g6fnemczm2smyxf%2bed0xxvcajiwhwte4ro; path=/; httponly vary: accept x-powered-by: express content-length: 78 connection: keep-alive  <p>moved temporarily. redirecting <a href="/auth/login">/auth/login</a></p> 

here see set-cookie header. , expect see cookie in next redirected request made api.misfitwearables.com itself. see here next:

get /auth/login http/1.1 host: api.misfitwearables.com accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 connection: keep-alive proxy-connection: keep-alive cookie: csrftoken=haf3px9l6vb9drtjtneqvsjsaimztync;sessionid=txo4fhez18vl6mvjuwlelph1uyn1pkau user-agent: mozilla/5.0 (macintosh; intel mac os x 10_11_5) applewebkit/601.6.17 (khtml, gecko) version/9.1.1 safari/601.6.17 accept-language: ru referer: https://api.welltory.com/api2/api/version/ accept-encoding: gzip, deflate 

i've passed same test standalone safari , behaviour expected.

i don't understand able influence wkwebview way. i'll appreciate suggestions of way investigate strange behaviour.

upd: interesting thing noticed if first request contains cookie header set-cookie subsequent responses not work. looks bug , have no idea how fix it.

upd2: noticed looking @ other requests, set-cookie worked correctly. seems http client think 3xx redirects sequence single request, each of might bring same http headers first one, without paying attention domains of final destination url.

so if first request has "x-csrftoken: haf3px9l6vb9drtjtneqvsjsaimztync" header, second , third ones have either. same logic applied cookie.

and since of headers have reasons become replicated request request during redirect sequence execution, cookie header not obvious. didn't find direct rules behaviour.

btw, in case while first redirect made backend developed in team, asked server developer avoid using redirects our server way , provide me direct url of target server start authorisation process.