Как да решаваме кеширащи пъзели

Мрежата не може да функционира без кеширане. Между вас и сървъра има браузър и редица прокси сървъри, които кешират отговорите. Повечето от тях се обработват тихо от приложения, което значително намалява интернет трафика. Въпреки това, кеширането може също да причини странно поведение в уеб приложенията, ако не сте внимателни.

Погрижете се за заглавките

Кеширането се контролира от HTTP кода на състоянието и заглавките Last-Modified, Etag и Cache-Control, върнати при всяка заявка. При последователни заявки за един и същ URL адрес браузърът или проксито ще направи следното:

Извличане на предишни данни от вашия собствен кеш;
Попитайте сървъра дали данните са се променили;
Направете нова заявка.

Всичко това се прави основно от заглавката Cache-Control. Той предава три стойности, разделени със запетаи:

без съхранение или без кеш

no-store спира браузъра и всички проксита да кешират върнатите данни. Всяка заявка ще бъде изпратена директно до сървъра.

Алтернативата е без кеш. Браузърът/проксито прави заявка към сървъра и връща Last-Modified (дата и час) и/или Etag (хеш/контролна сума) в заглавката. Те присъстват в следващите заявки и ако отговорът не се е променил, сървърът връща състояние 304 Not Modified, което принуждава браузъра/проксито да използва кешираните данни. В противен случай новите данни се предават със статус 200 OK.

обществени или частни

Задаването на Cache-Control на public означава, че отговорът на сървъра ще бъде еднакъв за всички и данните ще бъдат кеширани от браузъра или проксито. Това е поведението по подразбиране и не е необходимо да се задава допълнително.

Указва времето в секунди, през което отговорът ще остане валиден. Например,отговорът max-age=60 означава, че браузърът/проксито може да кешира данните за една минута, преди да направи нова заявка.

Вашият сървър, език за програмиране или рамка обикновено могат да контролират тези настройки и не е нужно да се занимавате с тях - но можете. Да предположим, че искате да кеширате индивидуален потребителски отговор в JSON за 30 секунди на Ajax заявка, в PHP бихте направили това:

И в маршрутизатора Node.js / Express по този начин:

Отделете URL адреса на страницата и Ajax данните

Понякога настройването на HTTP заглавки не е достатъчно, поради различното поведение на браузърите при натискане на клавиша за връщане назад.

Във Firefox и Safari клавишът за връщане назад ще се опита да ви върне към предишната страница в последното й състояние, което означава, че URL адресът е променен и актуализиран с #hash или чрез закачане на събитията на History API.

На практика рядко има значение кой браузър използвате, но някои странности се случват. Представете си, че вашето приложение има пагинирана таблица със записи, в която потребителят може да търси и навигира с помощта на клавишите за навигация. Добрите разработчици използват метода на прогресивно подобрение, за да гарантират, че приложението работи във всички браузъри.

В резултат на това нашият сървър може да избере да върне HTML или JSON за същия URL адрес в зависимост от състоянието на заглавката X-Requested-With. За съжаление, това може да причини проблеми в Chrome и Edge, тъй като и JSON, и HTML могат да бъдат кеширани.

Да приемем, че след като навигирате в списъка, попадате на страницата http://myapp.com/list/?search=bob&page=42, , след което навигирате до друга страница и натиснете клавиша за връщане назад. Chrome преглежда кеша, вижда JSON за този URL адрес и го предоставя на потребителя! Опресняването на страницата решава проблема, така чекак ще бъде направена заявката без заглавката X-Requested-With. По-странното е, че Firefox работи според очакванията и поддържа страницата актуална.

За съжаление списъкът с проблеми не свършва дотук...

Избягвайте самоподписани SSL сертификати

В идеалния случай вашето приложение използва шифрования HTTPS протокол. Въпреки това, когато разработвате, няма нужда да купувате SSL сертификати за всичките 57 членове на екипа, защото имате възможност да използвате фиктивен, самоподписан сертификат и да щракнете върху „продължи“, когато браузърът ви каже да го направите.

Пазете се от това, тъй като Chrome (и всички браузъри, базирани на двигателя Blink) отказват да кешират данните на страницата, когато са изправени пред фалшиви сертификати. Това поведение е подобно на заглавката Cache-Control, зададена на no-store във всяка заявка.

Вашият тестов сайт ще работи според очакванията и никога няма да се натъкнете на проблема с един и същи URL адрес за страницата и данните, описани в предишната част на статията. Кешът просто не се използва и всички заявки отиват към сървъра. Там приложение с истински SSL сертификат ще кешира данните. И вашите потребители ще докладват странни JSON отговори в Chrome, които не можете да възпроизведете на вашата локална машина.

Да, това е един от онези кошмари, които продължават да преследват уеб разработките. И се надявам, че моят преглед ще ви помогне да избегнете това.