only-if-cached запытвае захаваны адказ у проксі

Запытайце ў супрацоўнага HTTP-кэша наяўны адказ і тлумачце 504 як прамашку, не ўспрымаючы дырэктыву як сеткавае абмежаванне выхаду.

Для запыту, які павінен выкарыстаць ужо захаваны адказ, HTTP вызначае Cache-Control: only-if-cached.

Кліент можа адправіць яго праз кэшавы HTTP-проксі:

curl --proxy http://127.0.0.1:3128 \
  --header 'Cache-Control: only-if-cached' \
  --include http://www.example.org/report

Кэш, які выконвае гэтую дырэктыву, павінен вярнуць захаваны адказ, узгоднены з іншымі абмежаваннямі запыту, або 504 Gateway Timeout, калі не можа задаволіць запыт. Тут 504 можа выражаць палітыку кэша, а не няўдалае TCP-злучэнне з проксі.

Дырэктыва не дазваляе састарэлы змест аўтаматычна. Свежасць, патрабаванні да праверкі і адпаведныя палі Vary па-ранейшаму важныя. Дырэктыва запыту no-cache можа, наадварот, патрабаваць паспяховай праверкі крыніцы перад паўторным выкарыстаннем.

Гэта таксама адрозніваецца ад налады афлайнавага рэжыму праверкі кэша. only-if-cached пераносіцца на асобным запыце і выражае, што кліент гатовы атрымаць.

Выкарыстоўвайце кэш, які падтрымлівае такія паводзіны. Праігнараваная дырэктыва запыту не з'яўляецца файрволам, таму строгае прадухіленне ўзыходнага трафіку патрабуе незалежна ўкаранёнай сеткавай або сервернай палітыкі.

Звычайны HTTPS CONNECT-проксі не бачыць зашыфраваныя HTTP-загалоўкі і не захоўвае аб'екты старонак з гэтага тунэлю. Прыклад наўмысна выкарыстоўвае просты HTTP-рэсурс, які кэш можа апрацаваць.

Падобныя артыкулы