2016-12-06 21 views
10

Próbuję włączyć obsługę eTag w mojej aplikacji. Używam Alamofire 4 w moim projekcie 3 swift.Obsługa eTag przy użyciu Alamofire 4

Wydaje się, że wytyczne stanowi przejrzysty obsługiwane przez URLRequest, który używa Alamofire:

NSURLCache and ETags

Ale to nie działa.

Oto nagłówek HTTP wysyłane przez serwer WWW:

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

Czy yo mieć jakąkolwiek wskazówkę?

Wielkie dzięki.

+0

Definiuj "To nie działa" – Lefteris

Odpowiedz

4

Domyślnie buforowanie jest włączone. Jeśli logujesz ruch HTTP w swojej aplikacji, możesz zobaczyć buforowane odpowiedzi, ale tym razem aplikacja nie wysyła żądań do serwera.

W przypadku, gdy URLSession postanawia zwrócić odpowiedź z pamięci podręcznej, zamiast iść na serwer, zobaczysz ten sam nagłówek odpowiedzi HTTP o nazwie Date.

Aby zapewnić działanie buforowania, należy sprawdzić pakiety sieciowe między aplikacją a serwerem.

+0

Właśnie obejrzałem [to] (https://docs-assets.developer.apple.com/published/d24b133ea3/http_caching_2x_820a949f-9d5d-4a85-9ca2-50b42b339e18.png) obraz z [tutaj] (https://developer.apple.com/documentation/foundation/nsurlrequest.cachepolicy). Wygląda na to, że klient MUSI automatycznie wykonać szybkie żądanie 'HEAD'. Moje pytanie brzmi: co się dzieje, jeśli twój serwer nie wysyła/nie wdraża żądań typu "HEAD"? Czy to oznacza, że ​​nie działałby w ogóle i zasadniczo za każdym razem, gdy faktycznie tworzyłbyś żądania GET, niezależnie od ustawienia cachePolicy: 'NSURLRequestUseProtocolCachePolicy'? – Honey

+0

@Honey na obrazie, istnieje ścieżka, w której HEAD nie jest wymagana. – paiv

+0

... dopóki odpowiedź nie zestarzeje się. Tylko wtedy, gdy jest nieaktualny, HEAD zostanie wydany. Jeśli serwer nie obsługuje HEAD, zasób zostanie oznaczony jako zmieniony. Należy to debugować, przechwytując pakiety HTTP, aby mieć pewność. – paiv

-1

Miałem ten sam problem.

Zamiast wysyłać \"ecf38288be2f23f6710cafeb1f344b8c\" powrotem do serwera

wysyłania "ecf38288be2f23f6710cafeb1f344b8c"

0

Jest to domyślna polityka cache podczas używania URLRequest.

Jeśli chcesz to zmienić i zobaczyć „prawdziwy” odpowiedź z sieci, tak aby można było obsługiwać wytycznych i StatusCode przez siebie, po prostu trzeba zmienić politykę cache do reloadIgnoringCacheData:

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

Mam nadzieję, że to komuś pomaga!

+0

jak możesz * zmienić * zachowanie? Czy nie sugerujesz, że chcesz całkowicie zignorować pamięć podręczną? I po prostu pobierz bez względu na wszystko ?! – Honey

+0

Myślę, że to zależy od twojego przypadku użycia. Jeśli twój backend (lub, ogólnie rzecz biorąc, API, do którego dzwonisz) zawsze odpowiada 200 z pełną odpowiedzią, to zgadzam się z tobą, że musisz zachować buforowanie. Ale jeśli twój backend zaimplementował HTTP-Conditional-Get (tak, że odpowiada 200 z pełnym treścią, jeśli były jakieś zmiany i * 304 * z pustym ciałem, jeśli nie było żadnych), tak jak w moim przypadku, i potrzebujesz aby uzyskać dostęp do prawdziwego kodu statusu odpowiedzi (ponieważ w tym przypadku musisz wykonać określone czynności), musisz zmienić cachePolicy 'URLRequest'. –

Powiązane problemy