Содержание

HTTP Методы GET и POST



Два наиболее используемых метода HTTP: GET и POST.


Что такое HTTP?

Протокол HTTP предназначен для обеспечения связи между клиентами и серверами.

HTTP работает как протокол запроса-ответа между клиентом и сервером.

Веб-обозреватель может быть клиентом, а приложение на компьютере, на котором размещается веб-узел, может быть сервером.

Пример: клиент (обозреватель) отправляет HTTP-запрос на сервер; Затем сервер возвращает ответ клиенту. Ответ содержит сведения о состоянии запроса, а также может содержать запрошенное содержимое.


Два метода HTTP-запроса: Get и POST

Два часто используемых метода запроса-ответа между клиентом и сервером: Get и POST.

  • GET — Запрашивает данные из указанного ресурса
  • POST — Отправка данных для обработки в указанный ресурс

Метод Get

Обратите внимание, что строка запроса (пары «имя-значение») отправляется в URL-адрес запроса GET:

/test/demo_form.

php?name1=value1&name2=value2

Некоторые другие заметки о запросах GET:

  • GET запросы могут кэшироваться
  • GET запросы остаются в истории браузера
  • GET запросы могут быть закладками
  • GET запросы никогда не должны использоваться при работе с конфиденциальными данными
  • GET запросы имеют ограничения по длине
  • GET запросы должны использоваться только для извлечения данных

Метод POST

Обратите внимание, что строка запроса (пары «имя-значение») отправляется в теле HTTP-сообщения запроса POST:

POST /test/demo_form.php HTTP/1.1
Host: html5css.ru
name1=value1&name2=value2

Некоторые другие примечания по запросам POST:

  • POST запросы никогда не кэшируются
  • Запросы POST не сохраняются в журнале обозревателя
  • Запросы POST не могут быть закладками
  • Запросы POST не имеют ограничений по длине данных


Сравнить GET vs.

POST

В следующей таблице сравниваются два метода HTTP: Get и POST.


Никогда не используйте Get при отправке паролей или другой конфиденциальной информации!
  GET POST
Кнопка возврата/перезагрузка Безвредны Данные будут повторно отправлены (браузер должен предупредить пользователя о том, что данные будут повторно отправлены)
Закладка Можно закладка Не может быть Закладка
Кэшированные Может кэшироваться Не кэшируется
Тип кодировки application/x-www-form-urlencoded application/x-www-form-urlencoded or multipart/form-data. Использование многокомпонентной кодировки для двоичных данных
Истории Параметры остаются в журнале обозревателя Параметры не сохраняются в журнале обозревателя
Ограничения по длине данных Да, при отправке данных метод Get добавляет данные в URL-адрес; и длина URL ограничена (максимальная длина URL составляет 2048 символов) Без ограничений
Ограничения типа данных Разрешены только символы ASCII Никаких ограничений. Двоичные данные также разрешены
Безопасности Get менее безопасен по сравнению с POST, поскольку отправляемые данные являются частью URL-адреса
POST немного безопаснее, чем Get, поскольку параметры не сохраняются в журнале обозревателя или в журналах веб-сервера
Видимость Данные видны всем в URL Данные не отображаются в URL-адресе

Другие методы HTTP-запросов

В следующей таблице перечислены некоторые другие методы HTTP-запросов:

Метод Описание
HEAD То же, что и Get, но возвращает только заголовки HTTP и не тело документа
PUT Загружает представление заданного URI
DELETE Удаляет указанный ресурс
OPTIONS Возвращает HTTP-методы, поддерживаемые сервером
CONNECT Преобразует подключение запроса к прозрачному туннелю TCP/IP

Меняем параметры запроса GET с помощью mod rewrite

Модуль rewrite сервера Apache предоставляет мощные возможности по перенаправленнию запросов.

Это позволяет ещё до обработки запроса, к примеру, в коде программы на PHP вашего сайта, выполнить рутинные операции по изменению адреса страницы, параметров запроса и т.п.

В данной статье мы рассмотрим случаи, когда необходимо убрать параметры GET, или наоборот добавить/изменить.

Общие принципы

Если вы уже знаете, что такое mod_rewrite, как им пользоваться под apache, то пропускайте эту часть статьи.

Apache управляется конфигурационными файлами с именем .htaccess в директориях сервера и выполняет соответствующие инструкции. Главным из них является файл находящийся в корне сайта. В подкаталогах вашего сайта также могут находится .htaccess файлы, дополняющие/изменяющие директивы заданные в файлах ближе к корню.

Вот пример типичной переадресации в CMS средствами «мод рерайт»:

# Типичное перенаправлние всех запросов на скрипт /index.php # данные инструкции размещаются в корне сайта в файле .htaccess <IfModule mod_rewrite. index\.php$ — [L] #2. Правило № 2 #Эта переадресация сложнее, она предваряется условиями #если запрашивают не файл RewriteCond %{REQUEST_FILENAME} !-f #если запрашивают не каталог RewriteCond %{REQUEST_FILENAME} !-d #тогда выполняется перенаправление на скрипт index.php RewriteRule . /index.php [L] </IfModule>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

# Типичное перенаправлние всех запросов на скрипт /index.php

# данные инструкции размещаются в корне сайта в файле .htaccess

<IfModule mod_rewrite.c>

#включаем использование модуля

RewriteEngine On

#устанавливаем базовый путь переадресации

RewriteBase /

 

#правила пишутся друг за другом и выполняются по порядку

#1. index\.php$ — [L]

#2. Правило № 2

#Эта переадресация сложнее, она предваряется условиями

#если запрашивают не файл

RewriteCond %{REQUEST_FILENAME} !-f

#если запрашивают не каталог

RewriteCond %{REQUEST_FILENAME} !-d

#тогда выполняется перенаправление на скрипт index.php

RewriteRule . /index.php [L]

</IfModule>

Этот базовый пример не сможет показать все разнообразие возможностей, посмотрите обязательно полное описание команд модуля Rewrite.

Есть отличие перенаправления от переадресации.

Перенаправление

Отличие заключается в том, что в первом случае происходит обработка запроса, так как будто он был выполнен к указанному в перенаправлении скрипту/файлу/адресу. В нашем случае мы направляем все запросы к index.php

Переадресация

При переадресации, а в этом случае я бы добавил специальный флаг [R]:

RewriteRule . vazniy-razdel\.php$ /new-address.php?prm=%1 [R=301,L]

Так мы заменили параметр param1 на prm.

WordPress. Обработка POST-запросов. Часть 1. Категория: Web-разработка • CMS WoprdPress

В процессе загрузки WordPress происходит множество событий. К каждому из этих событий можно привязать функцию, которая выполнит какое-то действие (action) или изменит данные (filter). Отправка формы не является исключением — мы можем «прицепить» свою функцию к подходящему хуку и обработать POST-данные.

Кодекс WordPress говорит, что данные формы нужно отправлять на admin-post.php в директории wp-admin. А сама форма должна содержать поле action. Посмотрим на исходный код этого скрипта:

if (!defined('WP_ADMIN')) {
    define('WP_ADMIN', true);
}

if (defined('ABSPATH')) {
    require_once(ABSPATH . 'wp-load.php');
} else {
    require_once(dirname(dirname(__FILE__)) .
'/wp-load.php'); } send_origin_headers(); require_once(ABSPATH . 'wp-admin/includes/admin.php'); nocache_headers(); do_action('admin_init'); $action = empty($_REQUEST['action']) ? '' : $_REQUEST['action']; if (!wp_validate_auth_cookie()) { // если пользователь не авторизован if (empty($action)) { do_action('admin_post_nopriv'); } else { do_action('admin_post_nopriv_'.$action); } } else { // если пользователь авторизован if (empty($action)) { do_action('admin_post'); } else { do_action('admin_post_'.$action); } }

Все очень просто:

  • когда пользователь не авторизован
    • если action не установлен, происходит событие admin_post_nopriv
    • если action установлен, происходит событие admin_post_nopriv_{action}
  • когда пользователь авторизован
    • если action не установлен, происходит событие admin_post
    • если action установлен, происходит событие admin_post_{action}

Все вышеописанные хуки можно применить и для GET запроса, если адрес примерно такой:

http://www. server.com/wp-admin/admin-post.php?action=some_action&data=some_data

Плагин «Форма обратной связи»

Давайте применим полученные знания на практике и создадим плагин, который позволит добавить на сайт форму обратной связи. Создаем директорию tokmakov-feedback и внутри нее — файл tokmakov-feedback.php

.

<?php
/*
Plugin Name: Форма обратной связи
Plugin URI: https://tokmakov.msk.ru
Description: Регистрирует шорткод [tokmakov-feedback] для формы обратной связи, отправляет сообщения на почту.
Version: 1.0
Author: Евгений Токмаков
Author URI: https://tokmakov.msk.ru
*/

register_activation_hook(__FILE__, function() {
    // проверяем права пользователя на активацию плагинов
    if (!current_user_can('activate_plugins')) {
        return;
    }
});

register_deactivation_hook(__FILE__, function() {
    // проверяем права пользователя на деактивацию плагинов
    if (!current_user_can('deactivate_plugins')) {
        return;
    }
});

Для начала зарегистрируем шорткод [tokmakov-feedback]:

/*
 * Регистрируем шорткод [tokmakov-feedback], который позволит
 * вставить форму обратной связи на страницу или запись блога
 */
add_shortcode('tokmakov-feedback', function () {
    ob_start();
    ?>
    <div>
        <div></div>
        <form action="<?= admin_url('admin-post.
php'); ?>" method="post"> <input type="hidden" name="action" value="tokmakov_feedback" /> <input type="hidden" name="redirect" value="<?= get_permalink(); ?>" /> <label for="name"> <span>Имя</span> <input type="text" name="name" value="" required /> </label> <label for="email"> <span>Email</span> <input type="text" name="email" value="" required /> </label> <label for="phone"> <span>Телефон</span> <input type="text" name="phone" value="" /> </label> <label for="message"> <span>Сообщение</span> <textarea name="message" required></textarea> </label> <input type="submit" value="Отправить" /> </form> </div> <?php return ob_get_clean(); });

У нас есть скрытое поле формы action со значением tokmakov_feedback — значит, нам доступны два хука:

  • admin_post_nopriv_tokmakov_feedback
  • admin_post_tokmakov_feedback

Форму мы должны обработать независимо от того, залогинился пользователь или нет:

/*
 * Обрабатываем отправленные данные формы обратной связи
 */
add_action('admin_post_nopriv_tokmakov_feedback', 'tokmakov_process_feedback_form');
add_action('admin_post_tokmakov_feedback', 'tokmakov_process_feedback_form');

function tokmakov_process_feedback_form() {
    /*
     * Здесь уже можно обрабатывать массивы $_POST или $_GET
     */
}

Что ж, давайте напишем функцию, которая будет обрабатывать данные формы и отправлять письмо администратору:

function tokmakov_process_feedback_form() {
    /*
     * Обрабатываем данные, полученные из формы
     */
    $data['name'] = trim(iconv_substr(strip_tags($_POST['name']), 0, 50));
    $data['email'] = trim(iconv_substr(strip_tags($_POST['email']), 0, 50));
    $data['phone'] = trim(iconv_substr(strip_tags($_POST['phone']), 0, 50));
    $data['message'] = trim(iconv_substr(strip_tags($_POST['message']), 0, 1000));

    // были допущены ошибки при заполнении формы?
    if (empty($data['name'])) {
        $errors[] = 'Не заполнено обязательное поле «Имя»';
    }
    if (empty($data['email'])) {
        $errors[] = 'Не заполнено обязательное поле «E-mail»';
    }
    if (empty($data['message'])) {
        $errors[] = 'Не заполнено обязательное поле «Сообщение»';
    }

    if (!empty($errors)) {
        /*
         * были допущены ошибки при заполнении формы, сохраняем введенные
         * пользователем данные, чтобы после редиректа снова показать форму,
         * заполненную введенными ранее даннными и сообщением об ошибке
         */
        $_SESSION['tokmakov_feedback']['success'] = false;
        $message = 'При заполнении формы были допущены ошибки';
        $_SESSION['tokmakov_feedback']['message'] = $message;
        $_SESSION['tokmakov_feedback']['errors'] = $errors;
        $_SESSION['tokmakov_feedback']['data'] = $data;
    } else {
        // отправляем письмо администратору
        if (tokmakov_sendmail($data)) {
            $_SESSION['tokmakov_feedback']['success'] = true;
            $message = 'Ваше сообщение успешно отправлено';
            $_SESSION['tokmakov_feedback']['message'] = $message;
        } else {
            $_SESSION['tokmakov_feedback']['success'] = false;
            $message = 'Произошла ошибка при отправке письма';
            $_SESSION['tokmakov_feedback']['message'] = $message;
            $_SESSION['tokmakov_feedback']['data'] = $data;
        }
    }

    // после отправки формы делаем редирект, чтобы предотвратить
    // повторную отправку, если пользователь обновит страницу
    $redirect = home_url();
    if (isset($_POST['redirect'])) {
        $redirect = $_POST['redirect'];
        $redirect = wp_validate_redirect($redirect, home_url());
    }
    wp_redirect($redirect);
    die();
}
function tokmakov_sendmail($data) {
    $message = 'Имя: ' .  $data['name'] . PHP_EOL;
    $message .= 'E-mail: ' . $data['email'] . PHP_EOL;
    if (!empty($data['phone'])) {
        $message .= 'Телефон: ' . $data['phone'] . PHP_EOL;
    }
    $message .= PHP_EOL . 'Сообщение: ' . PHP_EOL . $data['message'] . PHP_EOL;
    $result = wp_mail(
        get_bloginfo('admin_email'),
        'Заполнена форма обратной связи',
        $message
    );
    return $result;
}

Как видите, функция проверяет корректность данных и записывает результат проверки в сессию. Чтобы после редиректа показать результаты проверки пользователю. Если форма содержит ошибки, в сессию будут также записаны введенные пользователем данные. Будет некрасиво, если пользователь потратил время, чтобы написать сообщение, а мы это сообщение потеряем при проверке.

А теперь доработаем функцию, которая регистрирует шорткод. Кроме самой формы, она будет показывать сообщения об ошибках или сообщение об успешной отправке:

/*
 * Регистрируем шорткод [tokmakov-feedback], который позволит
 * вставить форму обратной связи на страницу или запись блога
 */
add_shortcode('tokmakov-feedback', function () {
    $name = '';
    $email = '';
    $phone = '';
    $message = '';
    if (isset($_SESSION['tokmakov_feedback']['data'])) {
        $name = htmlspecialchars($name);
        $email = htmlspecialchars($email);
        $phone = htmlspecialchars($phone);
        $message = htmlspecialchars($message);
    }
    ob_start();
    ?>
    <div>
        <div>
            <?php if (isset($_SESSION['tokmakov_feedback'])): ?>
                <p><?= $_SESSION['tokmakov_feedback']['message']; ?></p>
                <?php if (isset($_SESSION['tokmakov_feedback']['errors'])): ?>
                    <ul>
                    <?php foreach ($_SESSION['tokmakov_feedback']['errors'] as $error): ?>
                        <li><?= $error; ?></li>
                    <?php endforeach; ?>
                    </ul>
                <?php endif; ?>
                <?php unset($_SESSION['tokmakov_feedback']); ?>
            <?php endif; ?>
        </div>
        <form action="<?= admin_url('admin-post. php'); ?>" method="post">
            <input type="hidden" name="action" value="tokmakov_feedback" />
            <input type="hidden" name="redirect" value="<?= get_permalink(); ?>" />
            <label>
                <span>Имя</span>
                <input type="text" name="name" value="<?= $name; ?>" required />
            </label>
            <label>
                <span>E-mail</span>
                <input type="text" name="email" value="<?= $email; ?>" required />
            </label>
            <label>
                <span>Телефон</span>
                <input type="text" name="phone" value="<?= $phone; ?>" />
            </label>
            <label>
                <span>Сообщение</span>
                <textarea name="message" required><?= $message; ?></textarea>
            </label>
            <input type="submit" value="Отправить" />
        </form>
    </div>
    <?php
    return ob_get_clean();
});

Поскольку мы используем суперглобальный массив $_SESSION, давайте стартанем сессию при наступлении события init:

/*
 * Запускаем сессию, чтобы передавать сообщение о результате
 * обработки формы обратной связи после перезагрузки страницы
 */
add_action('init', function () {
    if (session_id() == '') {
        session_start();
    }
});

Если при проверке данных формы были обнаружены ошибки, элемент массива $_SESSION с ключом tokmakov_feedback будет содержать вот что:

Array
(
    [success] => false
    [message] => При заполнении формы были допущены ошибки
    [errors] => Array
        (
            [0] => Не заполнено обязательное поле «E-mail»
        )
    [data] => Array
        (
            [name] => Евгений
            [email] =>
            [phone] =>
            [message] => Какое-то сообщение
        )
)

Если данные формы были успешно отправлены, этот элемент массива будет таким:

Array
(
    [success] => true
    [message] => Ваше сообщение успешно отправлено
)

Скачать плагин «Форма обратной связи» можно здесь.

Поиск: CMS • Hook • POST • Web-разработка • WordPress • Событие • Форма • Обратная связь • Плагин • Plugin • Плагин • Feedback

Как nginx обрабатывает запросы

Как nginx обрабатывает запросы

Определение виртуального сервера по имени

nginx вначале решает, какой из серверов должен обработать запрос. Рассмотрим простую конфигурацию, где все три виртуальных сервера слушают на порту *:80:

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      80;
    server_name example.net www.example.net;
    ...
}

server {
    listen      80;
    server_name example.com www.example.com;
    ...
}

В этой конфигурации, чтобы определить, какому серверу следует направить запрос, nginx проверяет только поле “Host” заголовка запроса. Если его значение не соответствует ни одному из имён серверов или в заголовке запроса нет этого поля вовсе, nginx направит запрос в сервер по умолчанию для этого порта. В вышеприведённой конфигурации сервером по умолчанию будет первый сервер, что соответствует стандартному поведению nginx по умолчанию. Сервер по умолчанию можно задать явно с помощью параметра default_server в директиве listen:

server {
    listen      80 default_server;
    server_name example.net www.example.net;
    ...
}
Параметр default_server появился в версии 0.8.21. В более ранних версиях вместо него следует использовать параметр default.

Следует иметь в виду, что сервер по умолчанию является свойством слушающего порта, а не имени сервера. Подробнее это обсуждается ниже.

Как предотвратить обработку запросов без имени сервера

Если запросы без поля “Host” в заголовке не должны обрабатываться, можно определить сервер, который будет их отклонять:

server {
    listen      80;
    server_name "";
    return      444;
}

Здесь в качестве имени сервера указана пустая строка, которая соответствует запросам без поля “Host” в заголовке, и возвращается специальный для nginx код 444, который закрывает соединение.

Начиная с версии 0.8.48 настройка server_name "" является стандартной и может явно не указываться. В более ранних версиях в качестве стандартного имени сервера выступало имя машины (hostname).
Определение виртуального сервера по имени и IP-адресу

Рассмотрим более сложную конфигурацию, в которой некоторые виртуальные серверы слушают на разных адресах:

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      192.168.1.1:80;
    server_name example.net www.example.net;
    ...
}

server {
    listen      192.168.1.2:80;
    server_name example.com www.example.com;
    ...
}

В этой конфигурации nginx вначале сопоставляет IP-адрес и порт запроса с директивами listen в блоках server. Затем он сопоставляет значение поля “Host” заголовка запроса с директивами server_name в блоках server, которые соответствуют IP-адресу и порту. Если имя сервера не найдено, запрос будет обработан в сервере по умолчанию. Например, запрос www.example.com, пришедший на порт 192.168.1.1:80, будет обработан сервером по умолчанию для порта 192.168.1.1:80, т.е. первым сервером, т.к. для этого порта www.example.com не указан в списке имён серверов.

Как уже говорилось, сервер по умолчанию является свойством слушающего порта, поэтому у разных портов могут быть определены свои серверы по умолчанию:

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      192.168.1.1:80 default_server;
    server_name example.net www.example.net;
    ...
}

server {
    listen      192.168.1.2:80 default_server;
    server_name example.com www.example.com;
    ...
}
Конфигурация простого сайта PHP

Теперь посмотрим на то, как nginx выбирает location для обработки запроса на примере обычного простого PHP-сайта:

server {
    listen      80;
    server_name example. org www.example.org;
    root        /data/www;

    location / {
        index   index.html index.php;
    }

    location ~* \.(gif|jpg|png)$ {
        expires 30d;
    }

    location ~ \.php$ {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME
                      $document_root$fastcgi_script_name;
        include       fastcgi_params;
    }
}

nginx вначале ищет среди всех префиксных location’ов, заданных строками, максимально совпадающий. В вышеприведённой конфигурации указан только один префиксный location “/”, и поскольку он подходит под любой запрос, он и будет использован, если других совпадений не будет найдено. Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location. Если запросу не соответствует ни одно из регулярных выражений, nginx использует максимально совпавший префиксный location, найденный ранее.

Следует иметь в виду, что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов. Так делается потому, что аргументы в строке запроса могут быть заданы различными способами, например:

/index.php?user=john&page=1
/index.php?page=1&user=john

Кроме того, в строке запроса можно запросить что угодно:

/index.php?page=1&something+else&user=john

Теперь посмотрим, как бы обрабатывались запросы в вышеприведённой конфигурации:

  • Запросу “/logo.gif” во-первых соответствует префиксный location “/”, а во-вторых — регулярное выражение “\.(gif|jpg|png)$”, поэтому он обрабатывается location’ом регулярного выражения. Согласно директиве “root /data/www” запрос отображается в файл /data/www/logo.gif, который и посылается клиенту.
  • Запросу “/index.php” также во-первых соответствует префиксный location “/”, а во-вторых — регулярное выражение “\. (php)$”. Следовательно, он обрабатывается location’ом регулярного выражения и запрос передаётся FastCGI-серверу, слушающему на localhost:9000. Директива fastcgi_param устанавливает FastCGI-параметр SCRIPT_FILENAME в “/data/www/index.php”, и сервер FastCGI выполняет указанный файл. Переменная $document_root равна значению директивы root, а переменная $fastcgi_script_name равна URI запроса, т.е. “/index.php”.
  • Запросу “/about.html” соответствует только префиксный location “/”, поэтому запрос обрабатывается в нём. Согласно директиве “root /data/www” запрос отображается в файл /data/www/about.html, который и посылается клиенту.
  • Обработка запроса “/” более сложная. Ему соответствует только префиксный location “/”, поэтому запрос обрабатывается в нём. Затем директива index проверяет существование индексных файлов согласно своих параметров и директиве “root /data/www”. Если файл /data/www/index.html не существует, а файл /data/www/index.php существует, то директива делает внутреннее перенаправление на “/index.php” и nginx снова сопоставляет его с location’ами, как если бы такой запрос был послан клиентом. Как мы видели ранее, перенаправленный запрос будет в конечном итоге обработан сервером FastCGI.
автор: Игорь Сысоев
редактор: Brian Mercer

Обработка запросов с помощью php

Основы клиент-серверных технологий

В самом начале курса мы уже говорили о том, что PHP – это скриптовый язык, обрабатываемый сервером. Сейчас мы хотим уточнить, что же такое сервер, какие функции он выполняет и какие вообще бывают серверы. Если речь идет о сервере, невольно всплывает в памяти понятие клиента. Все потому, что эти два понятия неразрывно связаны. Объединяет их компьютерная архитектура клиент-сервер. Обычно, когда говорят «сервер», имеют в виду сервер в архитектуре клиент-сервер, а когда говорят «клиент» – имеют в виду клиент в этой же архитектуре. Так что же это за архитектура? Суть ее в том, чтобы разделить функции между двумя подсистемами: клиентом, который отправляет запрос на выполнение каких-либо действий, и сервером, который выполняет этот запрос. Взаимодействие между клиентом и сервером происходит посредством стандартных специальных протоколов, таких как TCP/IP и z39.50. На самом деле протоколов очень много, они различаются по уровням. Мы рассмотрим только протокол прикладного уровня HTTP (чуть позднее), поскольку для решения наших программистских задач нужен только он. А пока вернемся к клиент-серверной архитектуре и разберемся, что же такое клиент и что такое сервер.

Сервер представляет собой набор программ, которые контролируют выполнение различных процессов. Соответственно, этот набор программ установлен на каком-то компьютере. Часто компьютер, на котором установлен сервер, и называют сервером. Основная функция компьютера-сервера – по запросу клиента запустить какой-либо определенный процесс и отправить клиенту результаты его работы.

Клиентом называют любой процесс, который пользуется услугами сервера. Клиентом может быть как пользователь, так и программа. Основная задача клиента – выполнение приложения и осуществление связи с сервером, когда этого требует приложение. То есть клиент должен предоставлять пользователю интерфейс для работы с приложением, реализовывать логику его работы и при необходимости отправлять задания серверу.

Взаимодействие между клиентом и сервером начинается по инициативе клиента. Клиент запрашивает вид обслуживания, устанавливает сеанс, получает нужные ему результаты и сообщает об окончании работы.

Услугами одного сервера чаще всего пользуется несколько клиентов одновременно. Поэтому каждый сервер должен иметь достаточно большую производительность и обеспечивать безопасность данных.

Логичнее всего устанавливать сервер на компьютере, входящем в какую-либо сеть, локальную или глобальную. Однако можно устанавливать сервер и на отдельно стоящий компьютер (тогда он будет являться одновременно и клиентом и сервером).

Существует множество типов серверов. Вот лишь некоторые из них.

Такой сервер специально приспособлен к обработке изображений, хранению видеоматериалов, видеоигр и т.п. В связи с этим компьютер, на котором установлен видеосервер, должен иметь высокую производительность и большую память.

  • Поисковый сервер предназначен для поиска информации в Internet.

  • Почтовый сервер предоставляет услуги в ответ на запросы, присланные по электронной почте.

  • Сервер WWW предназначен для работы в Internet.

  • Сервер баз данных выполняет обработку запросов к базам данных.

  • Сервер защиты данных предназначен для обеспечения безопасности данных (содержит, например, средства для идентификации паролей).

  • Сервер приложений предназначен для выполнения прикладных процессов. С одной стороны взаимодействует с клиентами, получая задания, а с другой – работает с базами данных, подбирая необходимые для обработки данные.

  • Сервер удаленного доступа обеспечивает коллективный удаленный доступ к данным.

  • Файловый сервер обеспечивает функционирование распределенных ресурсов, предоставляет услуги поиска, хранения, архивирования данных и возможность одновременного доступа к ним нескольких пользователей.

Обычно на компьютере-сервере работает сразу несколько программ-серверов. Одна занимается электронной почтой, другая распределением файлов, третья предоставляет web-страницы.

Из всех типов серверов нас в основном интересует сервер WWW. Часто его называют web-сервером, http-сервером или даже просто сервером. Что представляет собой web-сервер? Во-первых, это хранилище информационных ресурсов. Во-вторых, эти ресурсы хранятся и предоставляются пользователям в соответствии со стандартами Internet (такими, как протокол передачи данных HTTP). Как предоставляются данные в соответствии с этим протоколом, мы рассмотрим чуть позже. Работа с документами web-сервера осуществляется при помощи браузера (например, IE, Opera или Mozilla), который отсылает серверу запросы, созданные в соответствии с протоколом HTTP. В процессе выполнения задания сервер может связываться с другими серверами.

Далее в ходе лекции, говоря «сервер», мы будем подразумевать web-сервер.

В качестве примеров web-серверов можно привести сервер Apache группы Apache, Internet Information Server (IIS) компании Microsoft, SunOne фирмы Sun Microsystems,WebLogic фирмы BEA Systems, IAS (Inprise Application Server) фирмы Borland, WebSphere фирмы IBM, OAS (Oracle Application Server).

На рис. 4.1 и в таблице 4.1 приведена статистика использования различных серверов среди всех доменов Internet от NetCraft http://news. netcraft.com/.

Рис. 4.1.  Статистика использования ведущих web-серверов

Таблица 4.1. Ведущие разработчики web-серверов

Разработчик

Февраль 2004

Проценты

Март 2004

Проценты

Изменение

Apache

31703884

67.21

32280582

67. 20

-0.01

Microsoft

9849971

20.88

10099760

21.02

0.14

SunONE

1657295

3.51

1651575

3.44

-0.07

Zeus

755227

1. 60

762716

1.59

-0.01

Как видно из приведенной таблицы, сервер Apache занимает лидирующие позиции. Все, что мы когда-либо будем говорить о web-серверах, ориентировано на Apache, если не указано иное. О том, как установить его на свой компьютер, мы уже рассказывали в самой первой лекции. А теперь, как было обещано, обратимся к протоколу HTTP.

Разница между методами HTTP GET и POST

В этом руководстве вы узнаете, как отправлять информацию на сервер с помощью методов HTTP GET и POST и получать их с помощью PHP.

Способы отправки информации на сервер

Веб-браузер взаимодействует с сервером, как правило, с помощью одного из двух методов HTTP (протокола передачи гипертекста) — GET и POST. Оба метода передают информацию по-разному и имеют разные преимущества и недостатки, как описано ниже.

Метод GET

В методе GET данные отправляются как параметры URL, которые обычно представляют собой строки пар имени и значения, разделенные амперсандами ( и ). В целом URL-адрес с данными GET будет выглядеть так:

http://www.example.com/action.php? имя = Иоанн и возраст = 24

Полужирным шрифтом в URL-адресе выделены параметры GET, а выделенными курсивом — значения этих параметров.Более одного параметра = значение могут быть встроены в URL-адрес путем объединения с амперсандами ( и ). С помощью метода GET можно отправлять только простые текстовые данные.

Преимущества и недостатки использования метода GET

  • Поскольку данные, отправленные методом GET, отображаются в URL-адресе, можно добавить страницу в закладки с определенными значениями строки запроса.
  • Метод GET не подходит для передачи конфиденциальной информации, такой как имя пользователя и пароль, поскольку они полностью видны в строке запроса URL, а также потенциально хранятся в памяти браузера клиента как посещенная страница.
  • Поскольку метод GET назначает данные переменной среды сервера, длина URL-адреса ограничена. Таким образом, существует ограничение на отправку общих данных.

PHP предоставляет суперглобальную переменную $ _GET для доступа ко всей информации, отправляемой либо через URL-адрес, либо через HTML-форму с использованием method = "get" .

  


     Пример метода PHP GET 


 Привет,".$ _GET ["имя"]. "

"; } ?>
">

Метод POST

В методе POST данные отправляются на сервер в виде пакета в отдельном сообщении со сценарием обработки. Данные, отправленные с помощью метода POST, не будут отображаться в URL-адресе.

Преимущества и недостатки использования метода POST

  • Это более безопасно, чем GET, потому что вводимая пользователем информация никогда не отображается в строке запроса URL или в журналах сервера.
  • Существует гораздо больший лимит на объем передаваемых данных, и с помощью POST можно отправлять как текстовые, так и двоичные данные (загрузка файла).
  • Поскольку данные, отправленные методом POST, не отображаются в URL-адресе, невозможно добавить страницу в закладки с помощью определенного запроса.

Как и $ _GET , PHP предоставляет другую суперглобальную переменную $ _POST для доступа ко всей информации, отправляемой методом post или отправляемой через HTML-форму с использованием метода method = "post" .

  


     Пример метода PHP POST 


 Привет,". $ _POST ["имя"]. "

"; } ?>
">

Переменная $ _REQUEST

PHP предоставляет другую суперглобальную переменную $ _REQUEST , которая содержит значения переменных $ _GET и $ _POST , а также значения суперглобальной переменной $ _COOKIE .

  


     Пример переменной PHP $ _REQUEST 


 Привет,". $ _REQUEST ["имя"]. "

"; } ?>
">

Вы узнаете больше о файлах cookie PHP и обработке форм в расширенном разделе.

Примечание: Суперглобальные переменные $ _GET , $ _POST и $ _REQUEST являются встроенными переменными, которые всегда доступны во всех областях сценария.

PHP GET и POST

$ _GET и $ _POST — суперглобальные переменные в PHP, которые используются для сбора данных из HTML-формы и URL.

Обработка форм PHP

В этой главе показано, как собирать данные формы от пользователей с помощью методов POST и GET.

Пример ниже содержит HTML-форму с двумя полями ввода и кнопкой отправки:

Пример:

  


Имя: Электронная почта:

Когда пользователь заполняет и отправляет форму, данные формы будут отправлены в файл PHP: это называется регистрацией .php .

На странице registration.php есть следующий код для печати отправленных данных:

  


Добро пожаловать !
Ваш адрес электронной почты: 


  

Вывод программы:

 Добро пожаловать, Алекс!
Ваш адрес электронной почты: [email protected] 

Форма метода GET / POST и PHP $ _GET / $ _ POST

Существует два способа, которыми браузер (клиент) может отправлять информацию на веб-сервер.

  • Метод GET
  • Метод POST

Переменная PHP $ _GET

В PHP переменная $ _GET используется для сбора значений из HTML-форм с помощью метода get .

Информация, отправленная из HTML-формы с помощью метода GET, отображается в адресной строке браузера, и у нее есть ограничение на объем отправляемой информации.

Пример:

  


Имя: Электронная почта:

Когда пользователь нажимает кнопку «Отправить», URL-адрес будет примерно таким:

registration.php выглядит так:

  


Добро пожаловать !
Ваш адрес электронной почты: 


  

Когда использовать method = «get»?

  • Имена и значения переменных будут отображаться в URL, если HTML-формы отправлены методом GET.
  • Метод GET ограничен отправкой до 2048 символов только .
  • Когда вы отправляете конфиденциальную информацию, например пароли, не следует использовать этот метод.
  • Метод GET нельзя использовать для отправки двоичных данных, таких как изображения и документы Word.
  • Доступ к данным метода GET можно получить с помощью переменной среды PHP QUERY_STRING.
  • Ассоциативный массив PHP $ _GET используется для доступа ко всей отправленной информации методом GET.

Переменная PHP $ _POST

В PHP переменная $ _POST используется для сбора значений из HTML-форм с использованием метода post .

Информация, отправляемая из формы с помощью метода POST, невидима и не имеет ограничений на объем отправляемой информации.

Примечание: Однако по умолчанию для метода POST существует максимальный размер 8 МБ (можно изменить, установив post_max_size в файле php.ini).

Пример:

  


Имя: Электронная почта:

Когда пользователь нажимает кнопку «Отправить», URL-адрес будет примерно таким:

регистрация. php выглядит так:

Пример:

  


Добро пожаловать !
Ваш адрес электронной почты: 


  

Когда использовать method = «post»?

  • Метод POST не имеет ограничений на размер отправляемых данных.
  • Метод POST можно использовать для отправки ASCII, а также двоичных данных.
  • Данные, отправленные методом POST, проходят через заголовок HTTP, поэтому безопасность зависит от протокола HTTP.Используя Secure HTTP, вы можете быть уверены, что ваша информация в безопасности.
  • Ассоциативный массив PHP $ _POST используется для доступа ко всей отправленной информации методом POST.
  • Переменные не отображаются в URL-адресе, поэтому пользователи не могут добавить вашу страницу в закладки.

Переменная PHP $ _REQUEST

Переменная $ _REQUEST содержит содержимое $ _GET, $ _POST и $ _COOKIE.

Пример:

  


Добро пожаловать !
Ваш адрес электронной почты: 


  

Как обрабатываются запросы | Стандартная среда App Engine для PHP 5

ID региона

REGION_ID — это сокращенный код, который Google назначает в зависимости от региона, который вы выбираете при создании приложения.Код не соответствуют стране или провинции, хотя могут отображаться идентификаторы некоторых регионов похожи на обычно используемые коды стран и провинций. Включая REGION_ID .r в URL-адресах App Engine не является обязательным для существующие приложения и скоро потребуются для всех новых приложений.

Чтобы обеспечить плавный переход, мы медленно обновляем App Engine до используйте идентификаторы регионов. Если мы еще не обновили ваш проект Google Cloud, вы не будете увидеть идентификатор региона для вашего приложения. Поскольку идентификатор не является обязательным для существующих приложений, вы не нужно обновлять URL-адреса или вносить другие изменения, когда становится доступен идентификатор региона для ваших существующих приложений.

Узнать больше по поводу идентификаторов регионов.

Ok

В этом документе описывается, как ваше приложение App Engine получает запросы и отправляет ответы. Дополнительные сведения см. В справочнике по заголовкам и ответам запросов.

Если ваше приложение использует службы, вы можете адресовать запросы к определенной услуге или конкретной версии этого служба. Для получения дополнительной информации об адресности услуг см. Как бывают запросы Маршрутный.

Обработка запросов

Ваше приложение отвечает за запуск веб-сервера и обработку запросов. Вы можете использовать любую веб-платформу, доступную для вашего языка разработки.

App Engine запускает несколько экземпляров вашего приложения, и каждый У экземпляра есть собственный веб-сервер для обработки запросов. Любой запрос может быть перенаправлен к любому экземпляру, поэтому последовательные запросы от одного и того же пользователя не обязательно отправлено в тот же экземпляр. Экземпляр может обрабатывать несколько запросов одновременно. Количество экземпляров можно настроить автоматически по мере движения. изменения. Вы также можете изменить количество одновременных запросов, которые может обрабатывать экземпляр. установив max_concurrent_requests элемент в вашем приложении.yaml файл.

Сервер определяет, какой сценарий обработчика PHP запускать, сравнивая URL-адрес запрос к шаблонам URL в приложении app.yaml конфигурационный файл. Затем он запускает сценарий, заполненный данными запроса. В сервер помещает данные запроса в переменные среды и стандартный ввод транслировать. Скрипт выполняет действия, соответствующие запросу, а затем подготавливает ответ и помещает его в стандартный поток вывода.

Следующий пример представляет собой сценарий PHP, который отвечает на любой HTTP-запрос с сообщение «Hello World!»

Квоты и лимиты

App Engine автоматически выделяет ресурсы вашему приложению как трафик увеличивается.Однако это связано со следующими ограничениями:

  • App Engine резервирует возможность автоматического масштабирования для приложений с низкая задержка, когда приложение отвечает на запросы менее чем за один второй. Приложения с очень высокой задержкой, например, более одной секунды в запрос на множество запросов, а для высокой пропускной способности требуются Silver, Gold или Платиновая поддержка. Клиенты с таким уровнем поддержки могут запросить более высокие пределы пропускной способности, обратившись к представителю службы поддержки.

  • Приложения, которые сильно зависят от ЦП, также могут вызывать дополнительную задержку для эффективного совместного использования ресурсов с другими приложениями в том же серверы. Запросы на статические файлы освобождены от этих ограничений задержки.

Каждый входящий запрос к приложению засчитывается в лимит запросов . Данные, отправленные в ответ на запрос, засчитываются в Исходящая пропускная способность (оплачиваемая) лимит.

Запросы HTTP и HTTPS (безопасные) учитываются в Запросы , Входящие Пропускная способность (оплачиваемая) и Исходящая пропускная способность (оплачиваемая) лимитов.В Облачная консоль Страница сведений о квоте также сообщает Secure Requests , Secure Incoming Bandwidth и Безопасная исходящая пропускная способность как отдельные значения для информационных целей. При учете этих значений учитываются только запросы HTTPS. Для получения дополнительной информации см. Страница квот.

Следующие ограничения применяются конкретно к использованию обработчиков запросов:

Предел Сумма
размер запроса 32 мегабайта
размер ответа 32 мегабайта
тайм-аут запроса зависит от типа масштабирования, используемого вашим приложением
максимальное общее количество файлов (файлы приложений и статические файлы) 10,000 всего
1,000 на каталог
максимальный размер файла приложения 32 мегабайта
максимальный размер статического файла 32 мегабайта
максимальный общий размер всех приложений и статических файлов первый 1 гиг бесплатно
$ 0.026 за гигабайт в месяц после первого 1 гигабайта

Пределы реакции

Динамические ответы ограничены 32 МБ. Если обработчик скрипта генерирует ответ больше этого лимита, сервер отправляет пустой ответ с 500 Код состояния внутренней ошибки сервера. Это ограничение не распространяется на ответы которые обслуживают данные из Облачное хранилище .

Входящий HTTP-запрос включает HTTP-заголовки, отправленные клиентом. За в целях безопасности, некоторые заголовки очищаются или изменяются промежуточными прокси прежде, чем они достигнут приложения.

Для получения дополнительной информации см. Справку по заголовкам запросов.

Указание крайнего срока запроса

App Engine оптимизирован для приложений с недолговечными запросами, обычно те, которые занимают несколько сотен миллисекунд. Эффективное приложение отвечает быстро для большинства запросов. Приложение, которое плохо масштабируется с инфраструктурой App Engine.

Скрипт PHP имеет ограниченное количество времени для генерации и возврата ответа на запрос. Как только крайний срок был достигнут TIMEOUT бит на соединении битовое поле состояния установлен.Тогда у вашего скрипта будет короткий второй крайний срок, чтобы очистить любые длинные запущенные задачи и возвращение ответа пользователю.

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

Ответов

App Engine вызывает скрипт с заполненным массивом $ _REQUEST , буферизует любой вывод сценария, и когда сценарий завершает выполнение, отправляет буферизованный вывод конечному пользователю.

Существуют ограничения на размер ответа, который вы генерировать, и ответ может быть изменен, прежде чем он будет возвращен клиенту.

Дополнительные сведения см. В справке по запросам ответов.

Потоковые ответы

App Engine не поддерживает потоковые ответы, в которых данные отправляются в инкрементальные блоки для клиента во время обработки запроса. Все данные из вашего кода собирается, как описано выше, и отправляется как один HTTP отклик.

Сжатие отклика

App Engine делает все возможное, чтобы предоставлять сжатый (сжатый) контент для клиенты, которые его поддерживают.Чтобы определить, нужно ли сжимать контент, При получении запроса App Engine выполняет следующие действия:
  1. Подтверждает, может ли клиент надежно получать сжатые ответы, просматривая заголовки Accept-Encoding и User-Agent в запросе. Этот Этот подход позволяет избежать некоторых хорошо известных ошибок с gzip-содержимым в популярных браузерах.

  2. Подтверждает, подходит ли сжатие содержимого, просматривая Content-Type заголовок, который вы настроили для обработчик ответа.Как правило, сжатие подходит для текстовых типов контента, а не для двоичных типов содержимого.

Обратите внимание на следующее:

  • Клиент может принудительно сжать текстовые типы контента, установив оба заголовков запросов Accept-Encoding и User-Agent к gzip .

  • Если запрос не указывает gzip в заголовке Accept-Encoding , App Engine не сжимает данные ответа.

  • Google Frontend кэширует ответы из статического файла App Engine и обработчики каталогов. В зависимости от множества факторов, например от типа сначала кэшируются данные ответа, которые Варьируются заголовками , которые вы указали в ответ, и какие заголовки включены в запрос, клиент может запросить сжатые данные, но получать несжатые данные, и наоборот. За дополнительную информацию см. в разделе Кэширование ответов.

Кэширование ответов

Google Frontend и, возможно, браузер пользователя и другие промежуточные кэширующие прокси-серверы, будут кэшировать ответы вашего приложения в соответствии с инструкциями стандартные заголовки кеширования, которые вы указываете в ответе.Вы можете укажите эти заголовки ответов либо через ваш фреймворк, либо прямо в вашем код или через статический файл и каталог App Engine обработчики.

В Google Frontend ключ кеша — это полный URL-адрес запроса.

Кэширование статического содержимого

Чтобы клиенты всегда получали обновленный статический контент, как только он опубликовано, мы рекомендуем вам обслуживать статический контент из версионных каталоги, например css / v1 / styles.css . Google Frontend не проверяет кеш (проверьте наличие обновленного содержимого) до истечения срока действия кеша.Даже после срок действия кеша истекает, кеш не будет обновляться до тех пор, пока содержимое по запросу URL изменяется.

Следующие заголовки ответов, которые вы можете установить в ок. Yaml влияют на то, как и когда Google Frontend кэширует контент:

  • Cache-Control должен иметь значение public , чтобы Google Fontend мог кэшировать содержание. Если вы не установите этот заголовок в ок. Yaml , App Engine автоматически добавляет его для всех ответов, обрабатываемых статическим файлом или каталогом обработчик.Для получения дополнительной информации см. Заголовки добавлены или заменены.

  • Vary : чтобы кэш мог возвращать разные ответы для URL на основе заголовки, которые отправляются в запросе, устанавливают одно или несколько из следующих значений в заголовке ответа Vary : Accept , Accept-Encoding , Origin или X-Origin

    Из-за возможности высокой мощности, данные не будут кэшироваться для других Измените значения .

    Например:

    1. Вы указываете следующий заголовок ответа:

      Vary: Accept-Encoding

    2. Ваше приложение получает запрос, содержащий заголовок Accept-Encoding: gzip . App Engine возвращает сжатый ответ, а Google Frontend кэширует сжатую версию данных ответа. Все последующие запросы для этого URL-адреса, содержащего заголовок Accept-Encoding: gzip получит сжатые данные из кеша до тех пор, пока кеш не станет недействительным (из-за содержимое меняется после истечения срока действия кеша).

    3. Ваше приложение получает запрос, который не содержит Accept-Encoding заголовок. App Engine возвращает несжатый ответ, а Google Фронтенд кэширует несжатую версию данных ответа. Все последующие запросы для этого URL, которые не содержат заголовок Accept-Encoding будет получать сжатые данные из кеша, пока кеш не станет признан недействительным.

    Если вы не укажете заголовок ответа Vary , интерфейс Google Frontend создаст одна запись в кеше для URL-адреса и будет использовать ее для всех запросов независимо от заголовков в запросе. Например:

    1. Вы не указываете заголовок ответа Vary: Accept-Encoding .
    2. Запрос содержит заголовок Accept-Encoding: gzip и сжатый с помощью gzip версия данных ответа будет кэшироваться.
    3. Второй запрос не содержит заголовка Accept-Encoding: gzip . Однако, поскольку кеш содержит сжатую версию данных ответа, ответ будет сжат, даже если клиент запросил несжатый данные.

Заголовки в запросе также влияют на кеширование:

  • Если запрос содержит заголовок Authorization , содержимое не будет кешируется в Google Frontend.

Срок действия кеша

По умолчанию кэширующие заголовки статического файла App Engine и обработчики каталогов добавляют в ответы, инструктируют клиентов и веб-прокси, такие как Google Frontend истечет срок действия кеша через 10 минут.

После передачи файла с заданным сроком годности обычно нет способа очистить его из кешей веб-прокси, даже если пользователь очищает их собственный кеш браузера.Повторное развертывание новой версии приложения приведет к сбросу , а не . тайники. Поэтому, если вы когда-нибудь планируете изменить статический файл, он должен иметь короткий (менее часа) срок годности. В большинстве случаев по умолчанию 10 минут срок годности соответствующий.

Вы можете изменить срок действия по умолчанию для всех статических обработчиков файлов и каталогов. указав default_expiration элемент в вашем ок. Yaml файл. Чтобы установить конкретное время истечения срока действия для отдельных обработчики, указать срок действия элемент внутри элемента обработчика в вашем приложение.yaml файл.

Значение, указанное вами в элементе времени истечения срока, будет использоваться для установите заголовки ответа HTTP Cache-Control и Expires .

Кэширование приложений

Среда выполнения PHP включает OPcache, который может кэшировать PHP промежуточный код и значительно улучшить время отклика вашего приложения. Вы можете отключить кеширование OPcache, установив opcache.enabled = "0" в php.ini приложения файл.

Лесозаготовка

Веб-сервер App Engine фиксирует все, что пишет сценарий обработчика. в стандартный поток вывода для ответа на веб-запрос.Это также фиксирует все, что сценарий обработчика записывает в стандартный поток ошибок, и сохраняет его как данные журнала. Данные журнала для вашего приложения можно просмотреть в Облачная консоль с использованием Облачный журнал.

Среда выполнения PHP App Engine включает поддержку ведения журнала. произвольные сообщения из вашего приложения с использованием встроенного PHP syslog () функция , который вызывает Логи API.

Окружающая среда

Принудительное подключение HTTPS

По соображениям безопасности все приложения должны поощрять клиентов подключаться через https .Чтобы указать браузеру предпочесть https вместо http для данной страницы или весь домен, установите заголовок Strict-Transport-Security в своих ответах. Например:

  Strict-Transport-Security: max-age = 31536000; includeSubDomains
  
Чтобы установить этот заголовок для любого статического содержимого, обслуживаемого вашим приложением, добавьте заголовок статического файла и каталога вашего приложения обработчики. Внимание! Клиенты, получившие заголовок в прошлом, откажутся подключаться, если https перестает работать или отключен по любой причине. Чтобы узнать больше, см. Шпаргалка по строгой безопасности транспорта HTTP.

методов Get и Post в PHP

PHP предоставляет два метода, с помощью которых клиент (браузер) может отправлять информацию на сервер. Эти методы приведены ниже и подробно обсуждаются:

  1. Метод GET
  2. Метод POST

Методы Get и Post — это методы HTTP-запроса, используемые внутри тега

для отправки данных формы на сервер.

Протокол HTTP

обеспечивает связь между клиентом и сервером, где браузер может быть клиентом, а приложение, работающее в компьютерной системе, на которой размещен ваш веб-сайт, может быть сервером.

Метод GET

Метод GET используется для отправки данных HTML-формы. Эти данные собираются для обработки предопределенной переменной $ _GET .

Информация, отправленная из HTML-формы с использованием метода GET, видна всем в адресной строке браузера, что означает, что все имена переменных и их значения будут отображаться в URL-адресе. Следовательно, метод get не защищен для отправки конфиденциальной информации.

Например,

localhost / gettest.php? username = Harry & bloodgroup = AB +

полужирным шрифтом в приведенном выше URL-адресе — это имя переменных, а курсив часть содержит значения для соответствующих переменных.

Обратите внимание, что с помощью метода GET можно отправить только ограниченный объем информации.

На примере разберемся, как работает метод GET —

Пример

Приведенный ниже код отобразит HTML-форму, содержащую два поля ввода и кнопку отправки.В этой HTML-форме мы использовали метод = «get» для отправки данных формы.

файл: test1.html

Имя пользователя:
Группа крови:


Создать тест. php, который будет принимать данные, отправленные с помощью HTML-формы.

файл: gettest.php

Добро пожаловать,
Ваша группа крови:

Когда пользователь нажимает кнопку Отправить после заполнения формы, URL-адрес, отправленный на сервер, может выглядеть примерно так:

локальный хост / gettest.php? username = Harry & bloodgroup = AB-

Результат будет выглядеть следующим образом:

Добро пожаловать, Гарри
Ваша группа крови: AB-
 

Преимущества метода GET (method = «get»)

  • Вы можете добавить страницу в закладки с определенной строкой запроса, потому что данные, отправленные методом GET, отображаются в URL.
  • GET-запросов можно кэшировать.
  • запросов GET всегда остаются в истории браузера.

Недостатки метода GET

  • Метод GET не следует использовать при отправке конфиденциальной информации.
  • Ограниченный объем данных можно отправить с помощью method = «get». Этот предел не должен превышать 2048 символов.
  • По соображениям безопасности никогда не используйте метод GET для отправки конфиденциальной информации, такой как имя пользователя и пароль, потому что он показывает их в URL-адресе.
  • Метод GET нельзя использовать для отправки двоичных данных (например, изображений или текстовых документов) на сервер.

Метод POST

Подобно методу GET, метод POST также используется для отправки данных HTML-формы. Но данные, отправленные этим методом, собираются предопределенной суперглобальной переменной $ _POST вместо $ _GET.

В отличие от метода GET, он не имеет ограничения на объем отправляемой информации. Информация, отправленная из HTML-формы с использованием метода POST, никому не видна.

Например,

локальный / посттест.php

Обратите внимание, что метод «post» более безопасен, чем метод «get», поскольку данные, отправленные с использованием метода POST, не видны пользователю.

На примере разберемся, как работает метод POST —

Пример

Приведенный ниже код отобразит HTML-форму, содержащую два поля ввода и кнопку отправки. В этой HTML-форме мы использовали метод = «post» для отправки данных формы.

файл: test2.html

Имя пользователя:
Группа крови:


Теперь создайте файл posttest.php , чтобы принять данные, отправленные с помощью HTML-формы.

файл: posttest. php

Добро пожаловать,
Ваша группа крови:

Когда пользователь нажимает кнопку Отправить после заполнения формы, URL-адрес, отправленный на сервер, может выглядеть примерно так:

localhost / posttest.php

Результат будет выглядеть следующим образом:

Добро пожаловать, Гарри
Ваша группа крови: O +
 

Преимущества метода POST (method = «post»)

  • Метод POST полезен для отправки любой конфиденциальной информации, потому что информация, отправленная с помощью метода POST, никому не видна.
  • Нет ограничений на размер данных, отправляемых с использованием метода POST. Используя этот метод, вы можете отправить большой объем информации.
  • Двоичные данные и данные ASCII также могут быть отправлены с использованием метода POST.
  • Безопасность данных зависит от протокола HTTP, поскольку информация, отправляемая с помощью метода POST, проходит через заголовок HTTP. Используя безопасный HTTP, вы можете быть уверены, что ваши данные в безопасности.

Недостатки метода POST

  • POST-запросы не кешируются.
  • POST-запросов никогда не остаются в истории браузера.
  • Невозможно добавить страницу в закладки, потому что переменные не отображаются в URL.

$ _REQUEST переменная

Переменная $ _REQUEST — это суперглобальная переменная , которая может содержать содержимое переменных $ _GET и $ _POST. Другими словами, переменная PHP $ _REQUEST используется для сбора данных формы, отправленных методами GET или POST. Он также может собирать данные для переменной $ _COOKIE, потому что это переменная, не зависящая от метода.


Как делать асинхронные запросы в PHP

Было сказано, что «ограничения стимулируют творчество. «Если это правда, то PHP — это язык, который созрел для творческих решений. Я только что потратил последнюю неделю на создание нашей библиотеки PHP для сегмента и обнаружил множество подходов, используемых для повышения производительности при выполнении запросов на стороне сервера.

При разработке клиентских библиотек для отправки данных в наш API один из наших главных приоритетов — убедиться, что ни один наш код не влияет на производительность вашего основного приложения. Это сложно, когда у вас есть однопоточный язык без общего доступа, такой как PHP.

Чтобы еще больше усложнить ситуацию, размещенные установки PHP бывают разных видов. Если вам повезет, ваш хостинг-провайдер позволит вам разветвлять процессы, записывать файлы и устанавливать собственные расширения. В противном случае вы делитесь установкой с некоторыми шумными соседями и можете загружать только файлы .php .

В идеале, мы хотим, чтобы процесс настройки был минимальным и учитывал самые разные варианты использования. Пока он работает с PHP (и, возможно, с одним или двумя общими сценариями), вы должны быть готовы сразу же погрузиться в него.

В итоге мы поэкспериментировали с тремя основными подходами к выполнению запросов в PHP. Вот что мы узнали.

One: быстрое открытие сокета

Лучшие результаты поиска для асинхронных запросов PHP используют один и тот же метод: запись в сокет, а затем его закрытие перед ожиданием ответа.

Идея здесь в том, что вы открываете соединение с сервером и затем записываете на него, как только оно будет готово. Поскольку запись в сокет выполняется быстро и ответ не требуется, вы закрываете соединение сразу после записи.Это избавляет вас от ожидания в течение одного времени в оба конца.

Но, как вы можете видеть из некоторых комментариев к StackOverflow, есть некоторые споры о том, что на самом деле здесь происходит. Это заставило меня задуматься: «Насколько асинхронный — это подход с использованием сокетов?»

Вот как выглядит наш собственный код с использованием сокетов:

Первоначальные результаты не были обнадеживающими. Один вызов fsockopen занимал более 300 миллисекунд, а иногда и намного дольше.

Как оказалось, fsockopen блокирует — совсем не асинхронно! Чтобы увидеть, что здесь происходит на самом деле, вам нужно погрузиться во внутреннее устройство того, как на самом деле работает fsockopen .

Когда fsockopen выбирает протокол для сокета, он сначала должен решить, какой тип сокета использовать. Этот метод обычно блокируется до тех пор, пока сокет не будет полностью подключен, прежде чем вернуть его.

Напоминаем, что основной протокол, по которому работает Интернет, называется TCP. Это гарантирует, что сообщения между компьютерами передаются надежно и правильно упорядочиваются. Поскольку почти весь HTTP работает через TCP, мы используем его в нашем API, чтобы упростить написание пользовательских клиентов.

Вот суть запуска сокета TCP:

  • Клиент отправляет серверу сообщение syn .

  • Сервер отвечает сообщением syn-ack .

  • Клиент отправляет последнее сообщение ack и начинает отправку данных.

Для тех, кто считает, это полный цикл, прежде чем мы сможем отправить данные на сервер, и до того, как fsockopen даже вернется. Как только соединение открыто, мы можем записать наши данные в сокет. Обычно установка соединения с нашими серверами может занять от 30 до 100 мс .

Хотя TCP-соединения относительно быстрые, главным виновником здесь является дополнительное рукопожатие, необходимое для SSL.

Реализация SSL работает поверх TCP. После того, как происходит рукопожатие TCP, клиент начинает рукопожатие TLS.

В итоге для установления SSL-соединения требуется 3 цикла туда и обратно, не говоря уже о времени, необходимом для настройки шифрования с открытым ключом.

SSL-соединения в браузере могут избежать некоторых из этих циклов обмена за счет повторного использования общего секрета, согласованного между клиентом и сервером. Поскольку обычные сокеты не используются совместно между исполнениями PHP, мы должны каждый раз использовать новый сокет и не можем повторно использовать секрет!

Можно использовать socket_set_nonblock для создания «неблокирующего» сокета. Это не заблокирует открытый вызов, но вам все равно придется подождать, прежде чем писать на него. Если вы не можете запланировать трудоемкую работу между открытием сокета и записью данных, загрузка вашей страницы все равно будет замедляться на ~ 100 мс .

Лучше всего открыть постоянный сокет с помощью pfsockopen .Это позволит повторно использовать более ранние подключения к сокетам, сделанные процессом PHP, который не требует каждый раз квитирования TCP. Хотя начальная задержка выше во время первого запроса, я смог отправить более 1000 событий в секунду с моей машины разработки. Кроме того, мы можем решить читать из буфера ответов при отладке или игнорировать его в производственной среде.

Подводя итог:

  • Сокеты все еще можно использовать, когда демон, выполняющий PHP, имеет ограниченные права.

  • fsockopen блокирует, и даже неблокирующие сокеты должны ждать перед записью.

  • Использование SSL приводит к значительному замедлению работы из-за дополнительных циклов приема-передачи и настройки шифрования.

  • Открытие соединения устанавливает обратный запрос каждой страницы ~ 100 мс .

  • pfsockopen будет заблокирован в первый раз, но может повторно использовать более ранние соединения без квитирования.

Два: запись в файл журнала

Сокеты отлично подходят, если у вас нет доступа к другим частям машины, но подход, который даст вам лучшую производительность, — это регистрировать все события в файле.Затем этот файл журнала может быть обработан «вне канала» рабочим процессом или заданием cron.

Файловый подход имеет преимущество минимизации исходящих запросов к API. Вместо того, чтобы делать запрос всякий раз, когда мы вызываем track или идентифицируем из нашего PHP-кода, наш рабочий процесс может делать запросы на 100 событий за раз.

Еще одно преимущество состоит в том, что процесс PHP может относительно быстро регистрироваться в файле, обрабатывая запись всего за несколько миллисекунд.Как только PHP открыл дескриптор файла, добавить к нему fwrite — простая задача. Файл журнала, по сути, действует как «очередь разделяемой памяти», чего трудно добиться в чистом PHP.

Для чтения из файла журнала аналитики мы написали простой загрузчик на Python, который использует нашу библиотеку пакетной обработки analytics-python . Чтобы файлы журнала не становились слишком большими, сценарий загрузки атомарно переименовывает файл. Активно записывающие файлы PHP по-прежнему могут записывать в свои существующие дескрипторы файлов в памяти, а новые запросы создают новый файл журнала там, где раньше находился старый.

В этом подходе не так уж много волшебства. Требуется дополнительная работа со стороны разработчика, чтобы настроить задание cron и отдельно установить нашу библиотеку python через PyPI. Основные выводы:

  • Запись в файл выполняется быстро и требует мало системных ресурсов.

  • Для ведения журнала требуется некоторое пространство на диске, и демон должен иметь возможность записи в файл.

  • Вы должны запустить рабочий процесс для внеполосной обработки зарегистрированных сообщений.

Три: форк

curl Process

В качестве последней альтернативы, ваш сервер может запустить exec для выполнения запросов с использованием разветвленного процесса curl . Запрос curl может выполняться как часть отдельного процесса, что позволяет отображать ваш PHP-код без блокировки соединения с сокетом.

С точки зрения производительности разветвление процесса находится между двумя из наших предыдущих подходов. Это намного быстрее, чем открытие сокета, но более ресурсоемко, чем открытие дескриптора файла.

Для выполнения разветвленного процесса curl наш сжатый код выглядит так:

Если мы работаем в производственном режиме, мы хотим убедиться, что мы не ждем вывода разветвленного процесса. Вот почему мы добавляем в нашу команду "> / dev / null 2> & 1 &" , чтобы гарантировать, что процесс правильно разветвляется и нигде не регистрируется.

Эквивалентная команда оболочки выглядит так:

Требуется немногим более 1 мс , чтобы выполнить форк процесса, который затем использует около 4 КБ резидентной памяти.В то время как процесс curl использует стандартный SSL 300 мс для выполнения запроса, вызов exec может сразу же вернуться к сценарию PHP! Это позволяет нам гораздо быстрее обслуживать страницу для наших клиентов.

На моей машине среднего размера я могу разветвлять около 100 HTTPS curl запросов в секунду без их накопления в памяти. Без SSL он может сделать значительно больше:

  • Формирование процесса без ожидания вывода выполняется быстро.

  • curl требует того же времени, чтобы сделать запрос как сокет, но он обрабатывается вне диапазона.

  • Разветвление curl требует только обычных примитивов unix.

  • Разветвление возвращает один запрос назад всего на несколько миллисекунд, но многие параллельные ветки начнут замедлять работу ваших серверов.

Сокращение исходящих запросов с помощью деструктора

Хотя это и не подход к выполнению асинхронных запросов, мы обнаружили, что функции деструктора помогают нам пакетировать запросы API.

Чтобы уменьшить количество запросов, которые мы делаем к нашему API, мы хотим поставить эти запросы в очередь в памяти, а затем отправить их в API. Без использования расширений времени выполнения это может произойти только при выполнении одного скрипта PHP.

Для этого создаем очередь на инициализацию. Когда сценарий завершает свое выполнение, мы отправляем все запросы в очереди в пакетном режиме:

Мы устанавливаем очередь при создании объекта, а затем очищаем очередь, когда объект готов к уничтожению.Это гарантирует, что наша очередь очищается только один раз за запрос.

Кроме того, мы можем создать сам сокет неблокирующим способом в конструкторе, а затем попытаться записать в него в деструкторе. Это дает больше времени для установления соединения, пока интерпретатор PHP занят попыткой визуализации страницы, но нам все равно придется подождать, прежде чем фактически писать в сокет.

Итак, что мы выбрали?

Наш святой Грааль — это реализация на чистом PHP, которая не взаимодействует с другими процессами, но при этом остается консервативной в том, что касается выполнения запросов.Мы хотели бы максимально упростить настройку разработчика, не требуя выделенной очереди на отдельном хосте.

На практике этого добиться крайне сложно. У каждого из наших методов есть оговорки и ограничения в зависимости от того, с каким объемом трафика вы имеете дело и что ваша система позволяет делать. Поскольку ни один подход не может охватить все варианты использования, мы создали разные адаптеры для поддержки разных пользователей с разными потребностями.

Первоначально мы использовали метод ветвления curl по умолчанию.Разветвление процесса не приводит к значительному снижению производительности при загрузке страницы и по-прежнему может масштабироваться до множества запросов в секунду на хост. Однако это ограничено конфигурацией хоста и может иметь страшные последствия, если ваша программа PHP начнет разветвлять слишком много процессов одновременно.

После перехода на постоянные сокеты мы решили сделать сокет нашим значением по умолчанию. Без квитирования TCP для каждого запроса сокеты могут обрабатывать тысячи запросов в секунду.Этот подход также имеет значительно лучшую переносимость, чем метод curl .

Для клиентов с действительно высоким трафиком, которые имеют немного больше контроля над своим оборудованием, мы по-прежнему поддерживаем файловую систему журнала. Если процесс, который на самом деле обслуживает PHP, не может повторно использовать соединения сокетов, то это лучший вариант с точки зрения производительности.

В конечном итоге нужно немного узнать об ограничениях вашей системы и ее профиля нагрузки. Все дело в том, чтобы определить, какие компромиссы вам удобнее.

Заинтересованы в использовании PHP с сегментами? Ознакомьтесь с нашей документацией или просмотрите каждый из наших адаптеров в репозитории github.

Edit 2/6/13: Первоначально я заявлял, что мы использовали метод ветвления curl по умолчанию и игнорировали постоянные сокеты в целом. После переключения на постоянные сокеты производительность подхода с использованием сокетов увеличилась настолько, что он стал нашим подходом по умолчанию. Он также имеет лучшую переносимость между установками PHP.


шт.Если вы используете WordPress, мы также выпустили плагин WordPress, который сделает все за вас!

Как nginx обрабатывает запрос

Как nginx обрабатывает запрос

Виртуальные серверы на основе имени

nginx сначала решает, какой сервер должен обработать запрос. Начнем с простой настройки где все три виртуальных сервера прослушивают порт *: 80:

server {
    слушать 80;
    имя_сервера example.org www.example.org;
    ...
}

server {
    слушать 80;
    имя_сервера example.net www.example.net;
    ...
}

server {
    слушать 80;
    имя_сервера example.com www.example.com;
    ...
}
 

В этой конфигурации nginx проверяет только поле заголовка запроса. «Хост», чтобы определить, на какой сервер следует направить запрос. Если его значение не соответствует ни одному имени сервера, или запрос вообще не содержит этого поля заголовка, тогда nginx направит запрос на сервер по умолчанию для этого порта.В приведенной выше конфигурации сервер по умолчанию является первым one — стандартное поведение nginx по умолчанию. Также можно явно указать, какой сервер должен быть по умолчанию, с параметром default_server в директиве прослушивания:

server {
    слушаем 80  default_server ;
    имя_сервера example. net www.example.net;
    ...
}
 
Параметр default_server доступен с версия 0.8.21. В более ранних версиях должен использоваться параметр по умолчанию вместо.

Обратите внимание, что сервер по умолчанию — это свойство порта прослушивания. а не имени сервера. Подробнее об этом позже.

Как предотвратить обработку запросов с неопределенными именами серверов

Если запросы без поля заголовка «Хост» не должны разрешено, можно определить сервер, который просто отбрасывает запросы:

server {
    слушать 80;
    имя сервера "";
    return 444;
}
 

Здесь для имени сервера задана пустая строка, которая будет соответствовать запросы без поля заголовка «Хост», и специальный нестандартный код nginx 444 возвращается, что закрывает соединение.

Начиная с версии 0.8.48, это значение по умолчанию для имя сервера, поэтому server_name "" можно не указывать. В более ранних версиях имя хоста машины использовалось как имя сервера по умолчанию.
Смешанные виртуальные серверы на основе имен и IP

Давайте посмотрим на более сложную конфигурацию где некоторые виртуальные серверы прослушивают разные адреса:

server {
    слушайте 192.168.1.1:80;
    имя_сервера example.org www.example.org;
    ...
}

server {
    слушайте 192.168.1.1:80;
    имя_сервера example.net www.example.net;
    ...
}

server {
    слушайте 192.168.1.2:80;
    имя_сервера example.com www.example.com;
    ...
}
 

В этой конфигурации nginx сначала проверяет IP-адрес и порт. запроса против слушать директивы из серверные блоки. Затем он проверяет «Хост» поле заголовка запроса против имя сервера записи сервер блоки, которые совпали IP-адрес и порт.Если имя сервера не найдено, запрос будет обработан сервер по умолчанию. Например, запрос на www.example.com получен на порт 192.168.1. 1:80 будет обрабатываться сервером по умолчанию порта 192.168.1.1:80, т.е. первым сервером, поскольку для этого порта не определено www.example.com .

Как уже говорилось, сервер по умолчанию — это свойство порта прослушивания, и разные серверы по умолчанию могут быть определены для разных портов:

server {
    Слушай 192.168.1.1: 80;
    имя_сервера example.org www.example.org;
    ...
}

server {
    слушайте 192.168.1.1:80  default_server ;
    имя_сервера example.net www.example.net;
    ...
}

server {
    слушаем 192.168.1.2:80  default_server ;
    имя_сервера example.com www.example.com;
    ...
}
 
Простая конфигурация сайта PHP

Теперь давайте посмотрим, как nginx выбирает местоположение для обработки запроса. для типичного простого сайта PHP:

server {
    слушать 80;
    пример server_name.org www.example.org;
    корень / данные / www;

    место расположения / {
        index index. html index.php;
    }

    расположение ~ * \. (gif | jpg | png) $ {
        истекает 30 дней;
    }

    расположение ~ \ .php $ {
        fastcgi_pass localhost: 9000;
        fastcgi_param SCRIPT_FILENAME
                      $ document_root $ fastcgi_script_name;
        включить fastcgi_params;
    }
}
 

nginx сначала ищет наиболее точное местоположение префикса, заданное буквальные строки независимо от указанного порядка.В конфигурации выше единственное расположение префикса — «/», и поскольку оно соответствует любой запрос будет использован в крайнем случае. Затем nginx проверяет местоположения, заданные регулярное выражение в порядке, указанном в файле конфигурации. Первое совпадающее выражение останавливает поиск, и nginx будет использовать это место расположения. Если ни одно регулярное выражение не соответствует запросу, то nginx использует наиболее точное расположение префикса, найденное ранее.

Обратите внимание, что местоположения всех типов проверяют только часть URI строки запроса. без аргументов.Это сделано потому, что аргументы в строке запроса могут быть указаны в несколькими способами, например:

/index.php?user=john&page=1
/index.php?page=1&user=john
 

Кроме того, любой может запросить что угодно в строке запроса:

/index.php?page=1&something+else&user=john
 

Теперь посмотрим, как будут обрабатываться запросы. в конфигурации выше:

  • Запрос « /logo.gif » соответствует префиксу местоположения. Сначала «/», а затем по регулярному выражению « \.(gif | jpg | png) долларов США », следовательно, он обрабатывается последним местоположением. Используя директиву « root / data / www » запрос отображается в файл /data/www/logo.gif , а файл отправляется клиенту.
  • Запрос « /index.php » также соответствует местоположению префикса. Сначала «/», а затем по регулярному выражению « \. (Php) $ ». Следовательно, он обрабатывается последним местоположением и запрос передается на сервер FastCGI, который прослушивает localhost: 9000.В fastcgi_param директива устанавливает параметр FastCGI SCRIPT_FILENAME с на « /data/www/index.php », и сервер FastCGI выполняет файл. Переменная $ document_root равна ценность корень директива и переменная $ fastcgi_script_name равна URI запроса, то есть « /index.php ».
  • Запрос « /about.html » соответствует местоположению префикса. Только «/», поэтому он обрабатывается в этом месте.С помощью директивы « root / data / www » запрос отображается в файл /data/www/about.html , и файл отправляется клиенту.
  • Обработка запроса «/» более сложна. Соответствует только префиксу «/«, следовательно, он обрабатывается этим местом. Затем индекс директивные тесты на наличие индексных файлов по его параметрам и директива « root / data / www ». Если файл / data / www / index.html не существует, и существует файл /data/www/index.php , тогда директива выполняет внутреннее перенаправление на « /index.php », и nginx снова ищет локации как если бы запрос был отправлен клиентом. Как мы видели ранее, перенаправленный запрос в конечном итоге будет обработан. сервером FastCGI.
написано Игорем Сысоевым
отредактировано Брайаном Мерсером

GET vs POST — Различие и сравнение

Различия в подаче форм

Принципиальное различие между METHOD = «GET» и METHOD = «POST» состоит в том, что они соответствуют различным HTTP-запросам , как определено в спецификациях HTTP.Процесс отправки для обоих методов начинается одинаково — набор данных формы создается браузером и затем кодируется способом, указанным в атрибуте enctype . Для METHOD = «POST атрибут enctype может быть multipart / form-data или application / x-www-form-urlencoded , тогда как для METHOD =» GET « только application / x- Допускается www-form-urlencoded . Этот набор данных формы затем передается на сервер.

Для отправки формы с METHOD = «GET» браузер создает URL, принимая значение атрибута action , добавляя ? к нему, затем добавив набор данных формы (закодированный с использованием типа содержимого application / x-www-form-urlencoded). Затем браузер обрабатывает этот URL-адрес, как если бы он перешел по ссылке (или как если бы пользователь ввел URL-адрес напрямую). Браузер делит URL-адрес на части и распознает хост, а затем отправляет этому хосту запрос GET с остальной частью URL-адреса в качестве аргумента.Сервер берет это оттуда. Обратите внимание, что этот процесс означает, что данные формы ограничены кодами ASCII. Особое внимание следует уделять кодированию и декодированию других типов символов при их передаче через URL-адрес в формате ASCII.

Отправка формы с METHOD = «POST» вызывает отправку запроса POST с использованием значения атрибута action и сообщения, созданного в соответствии с типом содержимого, указанным атрибутом enctype .

Плюсы и минусы

Поскольку данные формы отправляются как часть URL-адреса, когда используется GET

  • Данные формы ограничены кодами ASCII.Особое внимание следует уделять кодированию и декодированию других типов символов при их передаче через URL-адрес в формате ASCII. С другой стороны, двоичные данные, изображения и другие файлы могут быть отправлены через МЕТОД = «POST»
  • Все заполненные данные формы отображаются в URL-адресе. Более того, он также сохраняется в истории / журналах просмотра веб-страниц пользователя в браузере. Эти проблемы делают GET менее безопасным.
  • Однако одним из преимуществ отправки данных формы как части URL-адреса является то, что можно пометить URL-адреса в закладки и напрямую использовать их, полностью обойдя процесс заполнения формы.
  • Существует ограничение на то, сколько данных формы может быть отправлено, поскольку длина URL-адреса ограничена.
  • Детям со сценариями легче выявить уязвимости в системе, чтобы взломать ее. Например, Citibank был взломан путем изменения номеров счетов в строке URL. [1] Конечно, опытные хакеры или веб-разработчики могут выявить такие уязвимости, даже если используется POST; это просто немного сложнее. В общем, сервер должен с подозрением относиться к любым данным, отправляемым клиентом, и защищаться от небезопасных прямых ссылок на объекты.

Различия в обработке на стороне сервера

В принципе, обработка отправленных данных формы зависит от того, отправлено ли они с METHOD = «GET» или METHOD = «POST» . Поскольку данные кодируются по-разному, необходимы разные механизмы декодирования. Таким образом, в общем случае изменение МЕТОДА может потребовать изменения сценария, обрабатывающего отправку. Например, при использовании интерфейса CGI сценарий получает данные в переменной среды (QUERYSTRING), когда используется GET .Но когда используется POST , данные формы передаются в стандартном входном потоке ( stdin ), а количество байтов для чтения задается заголовком Content-length.

Рекомендуемое использование

GET рекомендуется при отправке «идемпотентных» форм — тех, которые «не меняют существенно состояние мира». Другими словами, формы, которые включают только запросы к базе данных. Другая точка зрения состоит в том, что несколько идемпотентных запросов будут иметь тот же эффект, что и один запрос.Если задействованы обновления базы данных или другие действия, такие как запуск электронной почты, рекомендуется использовать POST.

Из блога разработчиков Dropbox:

браузер не знает точно, что делает конкретная HTML-форма, но если форма отправляется через HTTP GET, браузер знает, что можно автоматически повторить попытку отправки в случае сетевой ошибки. Для форм, использующих HTTP POST, повторная попытка может быть небезопасной, поэтому браузер сначала запрашивает у пользователя подтверждение.

Запрос «GET» часто кэшируется, тогда как запрос «POST» — вряд ли.Для систем запросов это может иметь значительное влияние на эффективность, особенно если строки запроса простые, поскольку кеши могут обслуживать наиболее частые запросы.

В некоторых случаях использование POST рекомендуется даже для идемпотентных запросов:

  • Если данные формы будут содержать символы, отличные от ASCII (например, символы с диакритическими знаками), то МЕТОД = «GET» в принципе неприменим, хотя может работать на практике (в основном для символов ISO Latin 1).
  • Если набор данных формы большой — скажем, сотни символов — тогда METHOD = «GET» может вызвать практические проблемы с реализациями, которые не могут обрабатывать такие длинные URL-адреса.
  • Возможно, вы захотите избежать METHOD = «GET» , чтобы сделать его менее видимым для пользователей, как работает форма, особенно для того, чтобы сделать «скрытые» поля (INPUT TYPE = «HIDDEN») более скрытыми, поскольку они не отображаются в URL. Но даже если вы используете скрытые поля с METHOD = «POST» , они все равно появятся в исходном HTML-коде.

А как насчет HTTPS?

Обновлено 15 мая 2015 г .: В частности, при использовании HTTPS (HTTP через TLS / SSL) обеспечивает ли POST более высокий уровень безопасности, чем GET?

Это интересный вопрос. Допустим, вы делаете запрос GET на веб-страницу:

 ПОЛУЧИТЬ https://www.example.com/login.php?user=mickey&passwd=mini
 

Предполагая, что ваше интернет-соединение отслеживается, какая информация об этом запросе будет доступна для отслеживания? Если вместо этого используется POST, а данные пользователя и passwd включены в переменные POST, будет ли это более безопасно в случае соединений HTTPS?

Ответ — нет.Если вы сделаете такой запрос GET, злоумышленнику, отслеживающему ваш веб-трафик, будет известна только следующая информация:

  1. Тот факт, что вы установили HTTPS-соединение
  2. Имя хоста — www.example.com
  3. Общая длина запроса
  4. Длина ответа

Часть пути URL-адреса, то есть фактическая запрашиваемая страница, а также параметры строки запроса, защищены (зашифрованы), пока они передаются «по сети» i.е., в пути к серверу назначения. Ситуация точно такая же для запросов POST.

Конечно, веб-серверы имеют тенденцию регистрировать весь URL в виде обычного текста в своих журналах доступа; поэтому отправка конфиденциальной информации через GET — не лучшая идея. Это применимо независимо от того, используется ли HTTP или HTTPS.

Список литературы

.