Разработчици твърдят, че Safari в iOS 6 „чупи“ приложенията им поради агресивно кеширане

3
26

Уеб разработчици докладваха, че браузърът Safari в iOS 6 „чупи“ техните приложения заради агресивно кеширане. Дискусия за проблема в сайта за разработчици Stack Overflow обяснява, че Safari запомня сървърни отговори на определени заявки и ги използва повторно, въпреки че всеки път би трябвало да се генерира нов отговор.

Уеб заявките могат да приемат много форми, но има два основни вида: GET и POST. POST се използва, когато очаквате някакъв страничен ефект от действието си; при GET няма такъв ефект. Например: търсите книга в Amazon и тъй като търсенето не променя никакво състояние (не прави поръчка, не променя състоянието на сметката Ви или нещо в този ред на мисли), в случая е GET. Ако обаче натиснете бутона „Buy“, ще използвате POST, защото заявката предизвиква определен ефект – кредитната Ви карта бива таксувана, книгата – изпратена и т.н.

Заради тази фундаментална разлика в заявките, за двата вида има различни правила по подразбиране за кеширането. GET заявките обикновено се кешират, понеже резултатът от GET се очаква да бъде един и същ всеки път и тъй като няма (страничен) ефект от GET, няма особено значение дали браузърът праща заявка до сървъра или просто генерира кеширан отговор. POST от своя страна обаче по правило не може да се кешира. Ако искате да разберете какъв е резултатът от POST, трябва да пратите заявка до сървъра, защото отговорът може да е различен. Нека използваме примера с Amazon отново: кредитната Ви карта може да откаже транзакцията този път или книгата да бъде временно недостъпна.

Отговорите на POST все пак могат да бъдат кеширани, но според уточнение в протокола на HTTP, отговорите трябва изрично да посочват, че могат да бъдат кеширани. Отговорите на GET не се нуждаят от това изрично посочване.

Доказателства сочат, че Safari в iOS 6 игнорира тези правила. Разработчиците използват POST за операции със страничен ефект, но Safari кешира резултатите и не дава правилен отговор на заявката. В резултат на това приложенията могат лесно „да се счупят“.

В Stack Overflow бяха предложени известен брой решения на проблема. Когато разработчиците имат контрол над сървъра и над клиента могат да конфигурират сървъра да посочва изрично, че отговорите не могат да бъдат кеширани. Това не би трябвало да е наложително и не се изисква от никой друг браузър. Когато разработчиците имат контрол само над клиента, могат да добавят timestamp (код, който идентифицира определено явление) или нещо подобно за всяка POST заявка, за да са сигурни, че никои два POST-a не са идентични. Това би работило, ако допуснем, че сървърът „няма нищо против“ да получава timestamp, който не е поискал.

Засега Apple не коментира въпроса.

3
ДОБАВИ КОМЕНТАР

avatar
3 Коментари
0 Отговори на коментарите
0 Последователи
 
Коментарът с най-много реакции
Най-горещият коментар
  Абонирай се  
нови стари оценка
Извести ме за
aninfid
aninfid

Абе и „GET“ и „POST“ правят едно и също. Разликата е, че „GET“ го прави в адресното табло, докато „POST“ е скрито.

maxim4o
maxim4o

Не е баш така.

ftpkid
ftpkid

И поради това заключение, генерално правило е, когато клиента праща заявка за получаване на ресурс(снимки, html, css, php, js, flash), той(ресурса) да се получава по GET метода. С думи прости, когато получаваш нещо от сървъра. Обратното е при POST. Сега пиша коментар, в момента в който натисна „Изпращане“, php скрипта праща данни към/за сървъра по POST метода. GET има ограничение за изпратени данни, пък и, както посочи, е по URL полето. Някоя умна глава може да направи много бели, поради този прост, но от екзистенциално значение, факт.