Php input что это

Php input что это

php:// — Доступ к различным потокам ввода-вывода

Описание

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

php://stdin, php://stdout и php://stderr

php://stdin , php://stdout и php://stderr позволяют получить прямой доступ к соответствующим потокам ввода или вывода процесса PHP. Поток указывает на копию файлового дескриптора, таким образом, если вы откроете php://stdin и потом закроете его, вы закроете только вашу копию дескриптора. Актуальный поток, на который ссылается STDIN , остаётся неизменным. Рекомендуется просто использовать константы STDIN , STDOUT и STDERR вместо ручного открытия потоков, используя эти обёртки.

Поток php://stdin предназначен только для чтения, тогда как php://stdout и php://stderr предназначены только для записи.

php://input

php://input является потоком только для чтения, который позволяет вам читать необработанные данные из тела запроса. php://input недоступен с типом содержимого enctype="multipart/form-data" .

php://output

php://output является потоком только для записи, который позволяет вам записать данные в выходной буфер аналогично, как это делают функции print и echo .

php://fd

php://fd предоставляет прямой доступ к указанному файловому дескриптору. Например, php://fd/3 относится к файловому дескриптору 3.

php://memory и php://temp

php://memory и php://temp являются потоками для чтения/записи и позволяют сохранять временные данные в файлоподобной обёртке. Единственная разница между ними заключается в том, что php://memory будет всегда хранить данные в оперативной памяти, тогда как php://temp будет использовать временный файл в том случае, когда объем хранимой информации достигнет заданного лимита (по умолчанию 2 Мб). Расположение этого временного файла определяется аналогично функции sys_get_temp_dir() .

Размер лимита для php://temp может устанавливаться путём добавления /maxmemory:NN , где NN — это максимальный размер данных в байтах для хранения в памяти перед использованием временного файла.

php://filter

php://filter — это вид мета-обёртки, предназначенный для разрешения применения фильтров к потоку во время открытия. Это полезно для функционально полных файловых функций, таких как readfile() , file() и file_get_contents() , где нет возможности применить фильтр к потоку до того, как содержимое будет прочитано.

Поток php://filter принимает следующие параметры как часть своего пути. В одном пути можно указать несколько цепочек фильтров. Пожалуйста, ознакомьтесь с примерами и особенностями при использовании этих параметров.

Опции

Примеры

Пример #1 php://temp/maxmemory

Этот необязательный параметр позволяет установить лимит памяти до того, как php://temp начнёт использовать временный файл.

<?php
// Установка предела в 5 MB.
$fiveMBs = 5 * 1024 * 1024 ;
$fp = fopen ( «php://temp/maxmemory: $fiveMBs » , ‘r+’ );

fputs ( $fp , «hello\n» );

// Читаем то, что мы записали.
rewind ( $fp );
echo stream_get_contents ( $fp );
?>

Пример #2 php://filter/resource=<поток для фильтрации>

Этот параметр должен быть расположен в конце вашей спецификации php://filter и должен указывать на поток, который вы хотите фильтровать.

<?php
/* Это просто эквивалентно:
readfile(«http://www.example.com»);
так как на самом деле фильтры не указаны */

Пример #3 php://filter/read=<список фильтров для применения к цепочке чтения>

Этот параметр принимает один или более имён фильтров, разделённых вертикальной чертой | .

<?php
/* Этот скрипт выведет содержимое
www.example.com полностью в верхнем регистре */
readfile ( «php://filter/read=string.toupper/resource=http://www.example.com» );

/* Этот скрипт делает тоже самое, что вверхний, но
будет также кодировать алгоритмом ROT13 */
readfile ( «php://filter/read=string.toupper|string.rot13/resource=http://www.example.com» );
?>

Пример #4 php://filter/write=<список фильтров для применения к цепочке записи>

Этот параметр принимает один или более имён фильтров, разделённых вертикальной чертой | .

Php://input

Этот метод нужен чтобы получить содержимое POST и GET запросов?Чем уже $_POST и $_GEt не устроил? Зачем вообще нужен этот ужас?

Читая статью трудно въехать для чего нужны эти самые потоки. Ни примеров ни толквого изложения. http://www.php.net/manual/ru/wrappers.php.php

К примеру вам нужно отправить json сериализованную строку. Передавать это нужно через POST, потому что в GET длина этой самой строки ограничена, кажется, 4мя килобайтами.

Что же именно передается POST методом ?

А передается вот что:

Передавать что-то типа: abc=<json_string> не хочется, потому что нужно экранировать еще эту строку.

Поэтому мы просто скармливаем строку скрипту. На сервер прийдет что-то типа такого:

Естественно, сервер не умеет парсить такие запросы, поэтому нам на помощь приходит file_get_contents(‘php://input’);

Мы можем получить то, что нам прислали, без изменений, самим распарсить это и быть счастливым 🙂

Расскажите подробно про php://input, как пользоваться?

php://input возвращает все необработанные данные после HTTP-заголовков запроса, независимо от типа контента.

• application/x-www-form-urlencoded ( application/x-www-form-urlencoded тип application/x-www-form-urlencoded для простых форм- application/x-www-form-urlencoded ) или
• multipart/form-data-encoded (в основном multipart/form-data-encoded для загрузки файлов)

Если вы просто отправляете POST-ом обычную HTML-форму, запрос выглядит примерно так:

Но если вы много работаете с Ajax, может понадобиться обмен более сложными данными с типами (строка, int, bool) и структурами (массивы, объекты), поэтому в большинстве случаев JSON является лучшим выбором. Но запрос с JSON-полезной нагрузкой выглядел бы примерно так:

Теперь содержимое будет application/json (или, по крайней мере, ни один из вышеперечисленных), так что $_POST -wrapper из PHP не знает, как с этим справиться (пока).

Данные всё еще там, вы просто не можете получить к нему доступ через $_POST. Поэтому вам нужно получить его с «сыром» виде помощью file_get_contents(‘php://input’) (если он не закодирован в формате multipart/form-data).

Это также способ доступа к XML-данным или любому другому нестандартному типу контента.

# Reading Request Data

Usually data sent in a POST request is structured key/value pairs with a MIME type of application/x-www-form-urlencoded . However many applications such as web services require raw data, often in XML or JSON format, to be sent instead. This data can be read using one of two methods.

php://input is a stream that provides access to the raw request body.

$HTTP_RAW_POST_DATA is a global variable that contains the raw POST data. It is only available if the always_populate_raw_post_data directive in php.ini is enabled.

This variable has been deprecated since PHP version 5.6, and was removed in PHP 7.0.

Note that neither of these methods are available when the content type is set to multipart/form-data , which is used for file uploads.

# Reading POST data

Data from a POST request is stored in the superglobal

(opens new window) $_POST in the form of an associative array.

Note that accessing a non-existent array item generates a notice, so existence should always be checked with the isset() or empty() functions, or the null coalesce operator.

# Reading GET data

Data from a GET request is stored in the superglobal

(opens new window) $_GET in the form of an associative array.

Note that accessing a non-existent array item generates a notice, so existence should always be checked with the isset() or empty() functions, or the null coalesce operator.

Example: (for URL /topics.php?author=alice&topic=php )

# Handling file upload errors

The $_FILES["FILE_NAME"][‘error’] (where "FILE_NAME" is the value of the name attribute of the file input, present in your form) might contain one of the following values:

1. UPLOAD_ERR_OK — There is no error, the file uploaded with success.
2. UPLOAD_ERR_INI_SIZE — The uploaded file exceeds the upload_max_filesize directive in php.ini .
3. UPLOAD_ERR_PARTIAL — The uploaded file exceeds the MAX_FILE_SIZE directive that was specified in the HTML form.
4. UPLOAD_ERR_NO_FILE — No file was uploaded.
5. UPLOAD_ERR_NO_TMP_DIR — Missing a temporary folder. (From PHP 5.0.3).
6. UPLOAD_ERR_CANT_WRITE — Failed to write file to disk. (From PHP 5.1.0).
7. UPLOAD_ERR_EXTENSION — A PHP extension stopped the file upload. (From PHP 5.2.0).

An basic way to check for the errors, is as follows:

# Uploading files with HTTP PUT

(opens new window) for the HTTP PUT method used by some clients to store files on a server. PUT requests are much simpler than a file upload using POST requests and they look something like this:

Into your PHP code you would then do something like this:

(opens new window) you can read interesting SO question/answers about receiving file via HTTP PUT.

# Passing arrays by POST

Usually, an HTML form element submitted to PHP results in a single value. For example:

This results in the following output:

However, there may be cases where you want to pass an array of values. This can be done by adding a PHP-like suffix to the name of the HTML elements:

This results in the following output:

You can also specify the array indices, as either numbers or strings:

Which returns this output:

This technique can be used to avoid post-processing loops over the $_POST array, making your code leaner and more concise.

# Remarks

# Choosing between GET and POST

GET requests, are best for providing data that’s needed to render the page and may be used multiple times (search queries, data filters. ). They are a part of the URL, meaning that they can be bookmarked and are often reused.

POST requests on the other hand, are meant for submitting data to the server just once (contact forms, login forms. ). Unlike GET, which only accepts ASCII, POST requests also allow binary data, including file uploads

You can find a more detailed explanation of their differences here

# Request Data Vulnerabilities

Retrieving data from the $_GET and $_POST superglobals without any validation is considered bad practice, and opens up methods for users to potentially access or compromise data through code

(opens new window) . Invalid data should be checked for and rejected as to prevent such attacks.

Request data should be escaped depending on how it is being used in code, as noted here

(opens new window) . A few different escape functions for common data use cases can be found in this answer