Філіп Зуєв, Ірина Пономарьова, Володимир Якименко
http://www.lar.ru/

У всіх сучасних браузерах є кнопка "Back", яка дозволяє користувачеві повторно переглянути ті сторінки, які він уже бачив раніше.

Ці дві кнопки призначені для зручності користувача, але іноді після натискання на одну з них користувач замість сторінки, яку він очікував, бачить зовсім іншу.

Ця стаття була написана для того, щоб пояснити, чому це відбувається і як цього уникнути.

Сторінки бувають двох видів: статичні і динамічні (останні ще іноді називають скриптами). Статична сторінка завжди виглядає для користувача однаково. Динамічна сторінка, як правило, виглядає по-різному в залежності від того, які дані були передані від браузера сервера. Ми поговоримо про те, як ці дані передаються, коли будемо розповідати про відміну методів GET і POST.

Кожен раз, коли браузер запитує з сервера нову сторінку, він передає серверу інформацію, яка необхідна, щоб знайти або створити цю сторінку. Ця інформація обов'язково містить:

• адреса сторінки (який ще називають Universal Resource Locator - URL),
• зарезервоване слово HTTP-протоколу (GET або POST), яке повідомляє серверу, що саме користувач браузера хоче зробити зі сторінкою. Справа в тому, що деякі браузери дозволяють своїм користувачам не тільки переглядати сторінки з сервера, але і замінювати їх іншими сторінками на свій розсуд або навіть видаляти. Зрозуміло, сервер не кожному користувачеві дозволить змінювати або видаляти сторінки. Це зарезервоване слово називається "метод" або "метод протоколу http". Методи GET і POST використовуються для отримання сторінки з сервера, при цьому вони можуть посилати сервера додаткові дані, які сервер може використовувати для формування сторінки. Метод GET показує ці дані в адресному рядку браузера. Вони виглядають як символ "?" з будь - якої рядком після нього. Метод POST цього не робить, посилаючи сервера дані трохи іншим чином. Є і ще одна відмінність, про нього нижче.
  
  
• Браузер показує користувачеві сторінку і ще запам'ятовує її, щоб наступного разу не повторювати весь ресурсномісткий процес спілкування з сервером заново. Це називається "кешування" сторінки (від англ. Слова cache, що означає пам'ять, в якій програми, наприклад, браузери, зберігають інформацію для повторного застосування). Втім, сервер може разом зі сторінкою передати браузеру "прохання» - не кешувати. Відповіді від сервера, отримані методом POST, що не кешуються, якщо сервер явно не "попросив" браузер кешувати. Те ж саме відноситься до сторінок з адресою, який містить символ "?" з параметрами після нього.
  Відповіді, отримані методом GET, навпаки, кешуються за замовчуванням.

Кешування підвищує швидкість, з якою браузер показує сторінки. Чому ж тоді сервер може попросити браузер не кешувати сторінки? Уявіть собі сторінку, яка, наприклад, показує поточний час. Якщо браузер покаже цю сторінку, взявши її з кеша, то, зрозуміло, час на сторінці буде показано неправильно.

Існує індустріальний стандарт - rfc 2616 ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt , Який визначає, як виробники браузерів повинні реалізовувати функціональність, в тому числі і функціональність кнопки "Back". Функціональність кнопки "Refresh" НЕ окреслена в специфікації прямо, але до неї причетні розділи, присвячені кешування (параграфи 13.1 - 13.12).

При натисканні кнопки "Back" браузер повинен показувати в точності ту сторінку, яку користувач вже переглядав раніше (rfc 2616, параграф 13.13). Згідно зі специфікацією, браузер у відповідь на натискання кнопки "Back" не повинен робити запит до скрипту, а замість цього повинен показати користувачеві сторінку, яку браузер "запам'ятав" в кеш-пам'яті. У таких випадках, сторінка, яку користувач побачив після натискання кнопки "Back", буде не такою, яку йому видав би скрипт з сервера. Це означає, що вона буде містити застарілу інформацію, яка може ввести користувача в оману.

У ситуації, описаної вище, згідно rfc 2616, браузер повинен попередити користувача. Internet Explorer 6 показує в таких випадках наступний текст:

Іноді автор веб додатки вважає за краще не бентежити користувачів цим попередженням.

У таких випадках автору веб додатки треба змусити браузер або не показувати попередження і просто заново запитувати сторінку з сервера (якщо сторінка дійсно буде містити більш нову інформацію), або змусити браузер просто брати сторінку з кеш-пам'яті.

На жаль, специфікація не визначає ніякого способу, яким це можна було б зробити.

Є ще одна можлива проблема з кнопкою "Back". Користувачеві буде показана застаріла версія сторінки, і, якщо браузер не стане попереджати про це, користувач може бути введений в оману.

Третя можлива проблема - браузер запросить сторінку з сервера заново. Або він перед цим покаже користувачеві попередження "Увага: сторінка застаріла" або навіть не буде його показувати, а просто зробить запит.

Тоді серверний додаток отримає два запити з однаковими параметрами. Це може порушити роботу додатка. Наприклад, воно повторно відправить лист, якщо це додаток - поштова система. Якщо повторно запитана сторінка - це сторінка, на якій користувач вводить своє ім'я і пароль, щоб зареєструватися в системі, тоді додаток фактично отримає прохання ще раз авторизувати вже авторизованого користувача. Це в більшості випадків означає, що користувачеві буде видана сторінка з повідомленням про помилку.

Друга і третя з перерахованих проблем в тій же мірі відносяться і до кнопки "Refresh".

Рішення проблем пов'язаних з кнопкою "Back" відрізняються від рішень, які застосовні до "Refresh" через наступного обставини. У пункті 13.13 RFC 2616 визначено, що браузер не повинен враховувати "прохання" серверу не кешувати сторінки, коли він показує їх у відповідь на натискання кнопки "Back". В інших випадках, наприклад, при натисканні користувачем кнопки "Refresh" браузер зобов'язаний враховувати ці "прохання".

Тому проблеми, викликані тим, що браузер після натискання кнопки "Refresh" показує користувачеві застарілу версію сторінки, яку він взяв з кеша, можна вирішити простим забороною кешування.

Варіанти вирішення проблем, пов'язаних з кнопкою "Back":

1. Можна просто заборонити кнопку "Back", точніше, зробити так, що браузер буде ігнорувати будь-які натискання на неї. Для цього треба все посилання на сторінці написати не так: <A href="http://www.servername.com/index.php"> текст посилання </ A & gt, а так: <A href = "javascript: window.location .replace ( 'http://www.servername.com/index.php') "& gtтекст посилання </ A & gt Недолік - якщо користувач заборонив своєму браузеру виконувати javascript, тоді посилання виду <A href =" javascript: ... "> перестануть працювати .

2. Щоб вирішити проблему кнопки "Back", можна замінити ті посилання, які містять в собі параметри (наприклад, "http://www.servername.com/cgi-bin/script.cgi?parameter1=1&parameter2=2") на посилання, які виглядають так - "http://www.servername.com/cgi-bin/script_parameter1_1_parameter2_2.html". Кожне таке посилання виглядає для браузера як посилання на окремий html файл, в нашому прикладі цей файл називається script_parameter1_1_parameter2_2.html. Сервер зможе витягти з імені файлу всю необхідну інформацію, яку він раніше отримував з параметрів. При цьому способі потрібно налаштування веб сервера. Найпростіше це зробити за допомогою сторінки - обробника помилки 404 (page not found). Якщо ваш сервер - це apache (www.apache.org) то документацію по його настройці можна прочитати тут .

Недолік - ваш хостинг провайдер може не дозволити вам налаштовувати його сервер на ваш смак.

Перевага - працює в будь-яких браузерах з будь-якими налаштуваннями.

3. При цьому способі сервер інакше обробляє запити. Замість того, щоб видати браузеру сторінку, сервер посилає йому відповідь, описаний в специфікації http (rfc 2616 параграф 10.3.4) сенс якого в тому, що запитана браузером сторінка знаходиться за іншою адресою, і браузер повинен перенаправити свій запит на цю адресу.

У такій ситуації більшість браузерів не вважатимуть отриману ними в кінцевому рахунку сторінку сформованої скриптом.

Наприклад, сервер у відповідь на запит пошле браузеру такий http відповідь:

Браузер тоді запросить з сервера сторінку /new_location_for_page.html і покаже її користувачеві. Він не вважатиме її сторінкою, сформованої скриптом і, відповідно, не буде показувати користувачеві попереджень, коли той натисне "Back", щоб знову подивитися її.

Проблеми з кнопкою "Refresh" вирішуються простіше, ніж з кнопкою "Back", завдяки тому, що у випадку з кнопкою "Refresh" браузер зобов'язаний враховувати HTTP-заголовки, що посилаються йому сервером, за допомогою яких сервер може змінювати режим кешування, який використовує браузер .

Для цього відповідь від сервера повинен містити наступний HTTP-заголовок:

Cache-Control: no-cache = cookie, set-cookie, set-cookie2

Цей метод працює тільки з браузерами, які підтримують специфікацію 1.1. Втім, до таких належать браузери Internet Explorer і Netscape Navigator, починаючи з 4-х версій.

Друга поширена проблема з кнопкою "Refresh" наступна:

Натиснувши на кнопку "Refresh" користувач змушує свій браузер повторно надіслати такий самий запит, який був посланий раніше. Це може порушити роботу вашого застосування. Наприклад, ваш додаток спробує вставити такі ж дані в базу даних або повторно надіслати такий самий лист. Щоб уникнути цього, автору додатки доведеться переробити його в такий спосіб: в кожному запиті, який браузер відправляє серверу, повинен бути випадковий параметр, який різниться в кожному запиті від браузера і формується, наприклад, за допомогою javascript.

Кожен раз, обробивши запит, серверний додаток має запам'ятати, використовуючи для цього, наприклад, сесії, значення цього випадкового параметра, що надійшов в запиті.

Якщо після цього користувач натисне кнопку "Refresh", сервер отримає два повністю ідентичних запиту. Оскільки серверний додаток знає, що кожен запит повинен відрізнятися від попереднього як мінімум одним випадковим параметром, другий запит в такій ситуації він може проігнорувати.

Проблеми, пов'язані з використанням кнопок "Back" і "Refresh", часто ставлять в тупик як користувачів мережі Internet, вперше зіткнулися з нез'ясовним поведінкою використовуваного ними веб-додатки, так і програмістів, порівняно недавно почали самостійно розробляти такі програми. Автори статті сподіваються, що освітлені тут коротко причини виникаючих проблем і варіанти їх рішень допоможуть і тим, і іншим уникнути незрозумілих питань і заощадити час, який в іншому випадку було б даремно витрачено на винахід рішень, які вже не раз винаходили іншими людьми.