В статье «Передача POST данных через fetch в JavaScript» был приведён пример кода для передачи данных методом POST, используя второй параметр функции fetch. В него передавался объект со свойствами method и body. Куда передаётся название метода и объект URLSearchParams.
Сейчас мы поговорим об URLSearchParams. А точнее о его более мощном заменителе — FormData. Фактически, если в нашем примере простейшей авторизации на сайте мы изменим URLSearchParams на FormData, то никаких ошибок не будет. То есть вполне можно поменять это:
var params = new URLSearchParams();
params.set('login', login);
params.set('pass', pass);
fetch('/login_ajax.php', {
method: 'POST',
body: params
});На это:
var params = new FormData();
params.set('login', login);
params.set('pass', pass);
fetch('/login_ajax.php', {
method: 'POST',
body: params
});Но удобство FormData состоит в том, что при создании объекта этого класса ему можно передавать указатель на форму. Тогда из формы автоматически будут прочитаны все поля и занесены в объект, который будет передан в fetch. То есть можно тегу form поставить id равный «form» <form id="form">, а потом передать эту информацию в класс FormData:
var form = document.getElementById('form');
// form указывает на форму
var params = new FormData(form);
fetch('/login_ajax.php', {
method: 'POST',
body: params
});Можно сделать код ещё короче, убрав промежуточные переменные params и form:
fetch('/login_ajax.php', {
method: 'POST',
body: new FormData( document.getElementById('form') )
});При этом данные полей будут переданы как раньше. То есть в PHP массиве $_POST можно будет найти ключи «login» и «pass» со значениями из полей формы.
Была ли эта статья полезна?
Есть вопрос?
Закажите недорогой хостинг
Заказать
всего от 290 руб
To access the entity body of a POST or PUT request (or any other HTTP method):
$entityBody = file_get_contents('php://input');
Also, the STDIN constant is an already-open stream to php://input, so you can alternatively do:
$entityBody = stream_get_contents(STDIN);
From the PHP manual entry on I/O streamsdocs:
php://input is a read-only stream that allows you to read raw data
from the request body. In the case of POST requests, it is preferable
to use php://input instead of$HTTP_RAW_POST_DATAas it does not
depend on special php.ini directives. Moreover, for those cases where
$HTTP_RAW_POST_DATAis not populated by default, it is a potentially
less memory intensive alternative to activating
always_populate_raw_post_data. php://input is not available with
enctype=»multipart/form-data».
Specifically you’ll want to note that the php://input stream, regardless of how you access it in a web SAPI, is not seekable. This means that it can only be read once. If you’re working in an environment where large HTTP entity bodies are routinely uploaded you may wish to maintain the input in its stream form (rather than buffering it like the first example above).
To maintain the stream resource something like this can be helpful:
<?php
function detectRequestBody() {
$rawInput = fopen('php://input', 'r');
$tempStream = fopen('php://temp', 'r+');
stream_copy_to_stream($rawInput, $tempStream);
rewind($tempStream);
return $tempStream;
}
php://temp allows you to manage memory consumption because it will transparently switch to filesystem storage after a certain amount of data is stored (2M by default). This size can be manipulated in the php.ini file or by appending /maxmemory:NN, where NN is the maximum amount of data to keep in memory before using a temporary file, in bytes.
Of course, unless you have a really good reason for seeking on the input stream, you shouldn’t need this functionality in a web application. Reading the HTTP request entity body once is usually enough — don’t keep clients waiting all day while your app figures out what to do.
Note that php://input is not available for requests specifying a Content-Type: multipart/form-data header (enctype="multipart/form-data" in HTML forms). This results from PHP already having parsed the form data into the $_POST superglobal.
To access the entity body of a POST or PUT request (or any other HTTP method):
$entityBody = file_get_contents('php://input');
Also, the STDIN constant is an already-open stream to php://input, so you can alternatively do:
$entityBody = stream_get_contents(STDIN);
From the PHP manual entry on I/O streamsdocs:
php://input is a read-only stream that allows you to read raw data
from the request body. In the case of POST requests, it is preferable
to use php://input instead of$HTTP_RAW_POST_DATAas it does not
depend on special php.ini directives. Moreover, for those cases where
$HTTP_RAW_POST_DATAis not populated by default, it is a potentially
less memory intensive alternative to activating
always_populate_raw_post_data. php://input is not available with
enctype=»multipart/form-data».
Specifically you’ll want to note that the php://input stream, regardless of how you access it in a web SAPI, is not seekable. This means that it can only be read once. If you’re working in an environment where large HTTP entity bodies are routinely uploaded you may wish to maintain the input in its stream form (rather than buffering it like the first example above).
To maintain the stream resource something like this can be helpful:
<?php
function detectRequestBody() {
$rawInput = fopen('php://input', 'r');
$tempStream = fopen('php://temp', 'r+');
stream_copy_to_stream($rawInput, $tempStream);
rewind($tempStream);
return $tempStream;
}
php://temp allows you to manage memory consumption because it will transparently switch to filesystem storage after a certain amount of data is stored (2M by default). This size can be manipulated in the php.ini file or by appending /maxmemory:NN, where NN is the maximum amount of data to keep in memory before using a temporary file, in bytes.
Of course, unless you have a really good reason for seeking on the input stream, you shouldn’t need this functionality in a web application. Reading the HTTP request entity body once is usually enough — don’t keep clients waiting all day while your app figures out what to do.
Note that php://input is not available for requests specifying a Content-Type: multipart/form-data header (enctype="multipart/form-data" in HTML forms). This results from PHP already having parsed the form data into the $_POST superglobal.
Request body data will be placed to req.body. A few examples for decoding popular request data formats:
application/x-www-form-urlencodedapplication/jsonmultipart/form-data
Form URL Encoded
application/x-www-form-urlencoded is a default data format for sending forms:
<form method="POST" action="/">
<input type="text" name="username" placeholder="username">
<input type="submit">
</form>
Use express.urlencoded middleware:
const express = require('express');
const app = express();
/** Decode Form URL Encoded data */
app.use(express.urlencoded());
/** Show page with a form */
app.get('/', (req, res, next) => {
res.send(`<form method="POST" action="/">
<input type="text" name="username" placeholder="username">
<input type="submit">
</form>`);
});
/** Process POST request */
app.post('/', function (req, res, next) {
res.send(JSON.stringify(req.body));
});
/** Run the app */
app.listen(3000);
Run this code and open localhost:3000.
Fill the form and send. You will see a response:
JSON
application/json mostly used for AJAX (XMLHttpRequest) requests.
Use express.json:
const express = require('express');
const app = express();
/** Decode JSON data */
app.use(express.json());
/** Show page with a input field, button and javascript */
app.get('/', (req, res, next) => {
res.send(`<script src="https://cdn.jsdelivr.net/npm/@codexteam/ajax"></script>
<script>
var send = function() {
var username = document.getElementById('username').value;
ajax.post({
url: '/',
data: {
username: username
},
})
.then(response => {
console.log(response.body)
})
.catch(console.error);
}
</script>
<input type="text" name="username" placeholder="username" id="username">
<button onclick="send()">Send</button>`);
});
/** Process POST request */
app.post('/', function (req, res, next) {
res.send(JSON.stringify(req.body));
});
/** Run the app */
app.listen(3000);
Run this code, open localhost:3000 and toggle web console.
Fill the form and send it. In the console you will see a server response with data you have sent.
Form data
multipart/form-data used for sending files or form-data objects.
Express by default has no ability to parse this type of encoding. So you can use multer’s middlewares.
For example try multer().none() middleware for decoding text-only multipart form.
const express = require('express');
const app = express();
/** Require multer */
const multer = require('multer');
/** Show page with a form with a specific enctype */
app.get('/', (req, res, next) => {
res.send(`<form method="POST" action="/" enctype="multipart/form-data">
<input type="text" name="username" placeholder="username">
<input type="submit">
</form>`);
});
/** Process POST request with a mutter's middleware */
app.post('/', multer().none(), function (req, res, next) {
res.send(JSON.stringify(req.body));
});
/** Run the app */
app.listen(3000);
Example page looks the same as a first one.
Run this code and open localhost:3000.
Fill the form and send. You will see a response:
For files uploading you read «Usage» section in multer’s docs. Files data will be places to req.files.
Читаю информацию про http запросы.
В большинстве источников говорится, что запрос состоит из 4 пунктов и обязателен только первый (и третий, если есть тело)
- Строка запроса
- Заголовки
- Пустая строка
- Тело сообщения
Так вот, как я понял одно из отличий GET от POST в том, что в POST запросе все параметры можно передать «скрыто», а в GET запросе, если будет Query String, то пользователь в браузере ее увидит.
В общем я в Google Chrome открыл инструменты разработчика, network и полазил по сайтам, по просматривал тела GET и POST запросов.
Когда Chrome отображал информацию о POST запросах, там на уровне с вкладками General, Response Headers, Request Headers могли появляться еще вкладками, например Request Payload или Form Data или Query String Parametrs.
Собственно вопрос — в каких разделах запроса (и в каком виде) передается эта информация, из которых потом формируются вкладки Request Payload или Form Data или Query String Parametrs? Это json’ы, которые идут после пустой строки или это json’ы-словари, которые идут в Headers, но почему-то выделены в отдельные ветки?
