2016-12-06 3 views
10

J'essaie d'activer le support eTag dans mon application. J'utilise Alamofire 4 dans mon projet swift 3.Support eTag en utilisant Alamofire 4

Il semble que eTag est géré de manière transparente par URLRequest qui utilise Alamofire:

NSURLCache and ETags

Mais cela ne fonctionne pas.

Voici en-tête HTTP envoyé par le serveur web:

headers { 
    Connection = "keep-alive"; 
    "Content-Length" = 47152; 
    "Content-Type" = "application/json"; 
    Date = "Tue, 06 Dec 2016 22:43:18 GMT"; 
    Etag = "\"ecf38288be2f23f6710cafeb1f344b8c\""; 
} }) 

Avez-yo ont tout soupçon?

Merci beaucoup.

+0

Définir "Cela ne fonctionne pas" – Lefteris

Répondre

4

Par défaut, la mise en cache est activée. Si vous consignez le trafic HTTP dans votre application, vous pouvez voir des réponses mises en cache, sans que l'application ne fasse de demandes au serveur cette fois.

Dans le cas où URLSession décide de retourner la réponse mise en cache au lieu d'aller au serveur, vous verrez le même en-tête de réponse HTTP Date.

Pour vous assurer que la mise en cache fonctionne, vous devez inspecter les paquets réseau entre votre application et votre serveur.

+0

Je viens de regarder [this] (https://docs-assets.developer.apple.com/published/d24b133ea3/http_caching_2x_820a949f-9d5d-4a85-9ca2-50b42b339e18.png) image de [ici] (https://developer.apple.com/documentation/foundation/nsurlrequest.cachepolicy). Il semble que pour que cela fonctionne, le client DOIT automatiquement faire une rapide requête 'HEAD'. Ma question est la suivante: que se passe-t-il si votre serveur ne route/n'implémente pas les requêtes HEAD? Cela signifie-t-il que cela ne fonctionnerait pas du tout et fondamentalement chaque fois que vous feriez des requêtes 'GET' - quel que soit le paramétrage de cachePolicy:' NSURLRequestUseProtocolCachePolicy'? – Honey

+0

@Honey sur votre image, il y a un chemin où la tête n'est pas nécessaire. – paiv

+0

... jusqu'à ce que la réponse soit périmée. Seulement quand il est éventé, HEAD sera publié. Si le serveur ne gère pas HEAD, la ressource sera marquée comme modifiée. Vous devriez déboguer ceci en capturant des paquets HTTP pour être sûr. – paiv

-1

J'ai eu le même problème.

Au lieu d'envoyer \"ecf38288be2f23f6710cafeb1f344b8c\" au serveur

envoyer "ecf38288be2f23f6710cafeb1f344b8c"

0

C'est la politique de cache par défaut lors de l'utilisation d'un URLRequest.

Si vous voulez changer ce comportement et voir la réponse « réelle » du réseau, de sorte que vous pouvez gérer eTag et statusCode par vous-même, vous avez juste besoin de changer la politique de cache reloadIgnoringCacheData:

var exampleRequest = try! URLRequest(url: route, method: .post, headers: headers) 
// This is the important line. 
exampleRequest?.cachePolicy = .reloadIgnoringCacheData 

Espérons que cela aide quelqu'un!

+0

comment pouvez-vous alors * changer * le comportement? Ne suggérez-vous pas d'ignorer entièrement le cache? Et juste télécharger n'importe quoi ?! – Honey

+0

Je pense que cela dépend de votre cas d'utilisation. Si votre backend (ou, en général, l'API que vous appelez) répond toujours 200 avec la réponse complète, alors je suis d'accord avec vous que vous devez garder la mise en cache. Mais si votre backend implémentait HTTP-Conditional-Get (pour qu'il réponde à 200 avec le corps entier s'il y a eu des changements et * 304 * avec un corps vide s'il n'y en a pas), comme dans mon cas, et vous avez besoin pour accéder au statusCode réel de la réponse (car vous devez faire des actions spécifiques dans ce cas), vous devez changer le cacheRolicy 'URLRequest'. –