Правда про сесіях - все про it і програмуванні

Сторінка 3 з 7

GET- і POST-дані

Існує ще два методи, які клієнт може використовувати для
відсилання даних на сервер, і ці методи існують набагато довше кук.
Клієнт може помістити інформацію в запитуваній URLе в рядку запиту
або прямо в дорозі, хоча останній випадок вимагає специфічного
програмування, яка не висвітлено в цій статті. Як приклад
використання рядка запиту розглянемо наступний:
GET /index.php?foo=bar HTTP / 1.1
Host: www.example.org

Приймаючий скрипт index.php може звернутися до $ _GET [ 'foo'] для отримання значення параметра foo. Внаслідок цього, більшість PHP-розробників говорять про ці дані як про GET-даних
(Інші іноді посилаються на них як на дані з запиту або
URL-змінні). Найпоширенішою причиною плутанини є те, що
GET-дані можуть існувати і в POST-запиті, так як вони є
просто частиною запитуваної URLя і не залежать від методу запиту.

Іншим методом, яким клієнт може скористатися для
відсилання інформації, є використання вмісту HTTP-запиту.
Цей спосіб вимагає, щоб методом запиту був POST:
POST /index.php HTTP / 1.1
Host: www.example.org
Content-Type: application / x-www-form-urlencoded
Content-Length: 7
foo = bar

В цьому випадку приймає скрипт index.php може звертатися до $ _POST [ 'foo'] для отримання значення параметра foo. PHP-розробники зазвичай посилаються на ці дані як на POST-дані. і саме так браузер передає дані, що відсилаються формою, в якій зазначено method = "post".

Взагалі ж кажучи, запит може містити і обидва типи даних:
POST /index.php?getvar=foo HTTP / 1.1
Host: www.example.org
Content-Type: application / x-www-form-urlencoded
Content-Length: 11
postvar = bar

Ці два додаткових методу відправки даних в запиті можуть
забезпечити заміну кукам. На відміну від кук, підтримка GET- і POST-даних
не є опціональною, тому ці методи можуть також бути більш
надійними. Розглянемо унікальний ідентифікатор, званий PHPSESSID. включений в запитуваний URL:
GET /index.php?PHPSESSID=12345 HTTP / 1.1
Host: www.example.org

Цим досягається та ж мета, що і заголовком Cookie,
так як клієнт ідентифікує себе; однак такий спосіб вимагає набагато
більшої участі розробника. Як тільки кука встановлена, -
обов'язком браузера є повертати її в повторних запитів.
Для передачі ж унікального ідентифікатора за допомогою URLя розробник
повинен забезпечити, щоб всі посилання, кнопки відправки форм і т.п.
містили відповідний рядок запиту (втім, PHP може йому в цьому
допомогти, якщо ви дозволите директиву session.use_trans_sid). До
того ж, GET-дані відображаються в URLе і набагато вразливіші, ніж куки.
Фактично, нічого не підозрюючи, користувачі можуть зберегти такий
URL в закладках, послати його друга або зробити з ним що завгодно, що
може випадково розкрити унікальний ідентифікатор.

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

Як правило, справа в недостатній практиці програмування. Недосвідчені програмісти стають перед особою необхідності створення складних веб-додатків. Тому часто-густо допускаються помилки, яких уникнув би досвідчений програміст, такі як необгрунтоване використання функції printf () або неп.

Введення PHP, фактично, є розповсюдженим мовою для Web програмування. Задля досягнення цього статусу він пройшов безліч етапів, від простого мови для Web програмування який поступався багатьом (php3), до сьогоднішнього швидкого потужного і розширюється (PHP4). Тим більше приємно, ч.

Але спочатку пара офіційних заяв: Деякі з наведених у даній статті рішень відтворювані в PHP4, але, тим не менше, їх опис присутній і тут для більшої зручності читання і цілісності всієї статті. Деякі з описаних в даній статті особливостей у кінцевому релізі PHP5 можуть.