Mapbox-gl-native: Adding ?fresh=true to style URL doesn't reload the newest style changes

[ericrwolfe]

Platform: iOS
Mapbox SDK version: 3.5.0 beta 1

The following should force-reload a style URL. Instead, the previously loaded style JSON is reloaded:

func reloadStyleUrl(url: URL) {
    var components = URLComponents(url: url, resolvingAgainstBaseURL: false)!

    var items = components.queryItems ?? [URLQueryItem]()

    // ?fresh=true should bypass the cached style json
    items.append(URLQueryItem(name: "fresh", value: "true"))

    // Workaround to trick the SDK and force a style refresh:
    // items.append(URLQueryItem(name: "timestamp", value: "\(Date().timeIntervalSince1970)"))

    components.queryItems = items

    // The SDK will only reload a style if the URL's changed, so temporarily set the URL to nil
    self.mapView.styleURL = nil
    self.mapView.styleURL = components.url
}

[ericrwolfe]

Stepping through HTTPFileSource::request I'm getting an NSURLErrorCancelled.

URL :

https://api.mapbox.com/styles/v1/ericrwolfe/ciz5xuqq8000a2rmytt7po3u5/draft?access_token=<access_token>&fresh=true&events=true

Headers:

(lldb) po req.allHTTPHeaderFields
{
    "If-None-Match" = "W/\"1068c-O444/JKmuNkLM4SnfGh7Lw\"";
    "User-Agent" = "Mapbox GL/0.0.2 Mapbox/1.0.0 MapboxGL/0.0.0 (2f989bc9) iOS Simulator/10.2.0 (x86_64)";
}

Response headers when loaded externally, emphasis Cache-Control: no-cache and a different Etag:

HTTP/1.1 200 OK

Content-Type: application/json; charset=utf-8
X-Amz-Cf-Id: ziTG0ky992nLjO2Vqme80K50WnEuTLdamvLz12RnO2riflUQAHOhgA==
Access-Control-Allow-Origin: *
X-Powered-By: Express
Via: 1.1 f32e4aea3683be99c4324204c29f5852.cloudfront.net (CloudFront)
Content-Encoding: gzip
Transfer-Encoding: Identity
Cache-Control: no-cache
Date: Wed, 15 Feb 2017 19:28:31 GMT
Connection: keep-alive
Etag: W/"1068b-QMc3pRI8phxlCXakn7F1lQ"
Vary: Accept-Encoding
X-Cache: RefreshHit from cloudfront

Ideas on why the request is being cancelled @1ec5?

[1ec5]

Not sure. mbgl::HTTPRequest does cancel the request in its destructor; could that be related?

[ericrwolfe]

The destructor _is_ where the request is cancelled, but I couldn't figure out from the stack trace why mbgl::HTTPRequest would be destroyed before receiving a response.

/cc @jfirebaugh

[jfirebaugh]

It's triggering this code and aborting the revalidation request. Response::isFresh considers only the "expiration", as calculated from the Cache-Control header, and our parser ignores no-cache.

Correct behavior would be to treat a no-cache response as never fresh. This will certainly require modifying the parser so that it handles that header value, and may also require Response to hold an actual CacheControl value rather than reducing it to an "expiration" timestamp value.

[jfirebaugh]

Should a resource whose responses consistently have Cache-Control: no-cache be automatically revalidated? If so, on what schedule?

• If we were to treat no-cache the same as "expiration date in the past", then the behavior will be to perform an unlimited number of automatic revalidations, waiting an exponentially increasing amount of time between each one. That doesn't seem right.
• Alternative: automatically revalidate on some arbitrarily chosen _fixed_ interval. This also doesn't seem right. If fixed period revalidation was really what was wanted, the response should have had a max age.
• Alternative: don't automatically revalidate at all; fetch a new version of the resource only when it would be re-requested for natural reasons (app relaunches, tile becomes visible, manual setStyleURL, etc.). The preview app could manually trigger a refresh. This seems like the best answer.

[jfirebaugh]

Related: #7266.

[stale[bot]]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.