Get запрос c: http — Отправка GET/POST-запроса средствами чистого C++

Содержание

Сообщения HTTP — HTTP | MDN

HTTP сообщения — это обмен данными между сервером и клиентом. Есть два типа сообщений: запросы, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера, и ответы от сервера.

Сообщения HTTP состоят из текстовой информации в кодировке ASCII, записанной в несколько строк. В HTTP/1.1 и более ранних версиях они пересылались в качестве обычного текста. В HTTP/2 текстовое сообщение разделяется на фреймы, что позволяет выполнить оптимизацию и повысить производительность.

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

Механизм бинарного фрагментирования в HTTP/2 разработан так, чтобы не потребовалось вносить изменения в имеющиеся APIs и конфигурационные файлы: он вполне прозрачен для пользователя.

HTTP запросы и ответы имеют близкую структуру. Они состоят из:

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

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

телом.

Стартовая строка

HTTP запросы — это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трёх элементов:

Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть
- Абсолютный путь, за которым следует '?' и строка запроса. Это самая распространённая форма, называемая исходной формой (origin form) . Используется с методами GET, POST, HEAD, и OPTIONS.
  POST / HTTP 1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0
- Полный URL — абсолютная форма (absolute form) , обычно используется с GET при подключении к прокси.
  GET http://developer. mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1
- Компонента URL «authority», состоящая из имени домена и (необязательно) порта (предваряемого символом ':'), называется authority form. Используется только с методом CONNECT при установке туннеля HTTP.
  CONNECT developer.mozilla.org:80 HTTP/1.1
- Форма звёздочки (asterisk form), просто «звёздочка» ('*') используется с методом OPTIONS и представляет сервер.
  OPTIONS * HTTP/1.1
Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.

Заголовки

Заголовки запроса HTTP имеют стандартную для заголовка HTTP структуру: не зависящая от регистра строка, завершаемая (':') и значение, структура которого определяется заголовком. Весь заголовок, включая значение, представляет собой одну строку, которая может быть довольно длинной.

Существует множество заголовков запроса. Их можно разделить на несколько групп:

Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом

Заголовки запроса (Request headers), например, User-Agent, Accept-Type, уточняющие запрос (как, например, Accept-Language), придающие контекст (как Referer), или накладывающие ограничения на условия (like If-None).
Заголовки сущности, например Content-Length, относящиеся к телу сообщения. Как легко понять, они отсутствуют, если у запроса нет тела.

Тело

Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как GET, HEAD, DELETE, или

OPTIONS, в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм).

Тела можно грубо разделить на две категории:

Одноресурсные тела (Single-resource bodies), состоящие из одного отдельного файла, определяемого двумя заголовками: Content-Type и Content-Length.
Многоресурсные тела (Multiple-resource bodies), состоящие из множества частей, каждая из которых содержит свой бит информации. Они обычно связаны с HTML-формами .

Строка статуса (Status line)

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

Версию протокола, обычно HTTP/1.1.
Код состояния (status code), показывающая, был ли запрос успешным. Примеры: 200, 404 или 302
Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP..

Пример строки статуса: HTTP/1.1 404 Not Found.

Заголовки

Заголовки ответов HTTP имеют ту же структуру, что и все остальные заголовки: не зависящая от регистра строка, завершаемая двоеточием (':') и значение, структура которого определяется типом заголовка.

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

Существует множество заголовков ответов. Их можно разделить на несколько групп:

Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом.
Заголовки ответа (Response headers), например, Vary и Accept-Ranges, сообщающие дополнительную информацию о сервере, которая не уместилась в строку состояния.
Заголовки сущности (Entity headers), например, Content-Length, относящиеся к телу ответа. Отсутствуют, если у запроса нет тела.

Тело

Последней частью ответа является его тело. Оно есть не у всех ответов: у ответов с кодом состояния, например, 201 или 204, оно обычно отсутствует.

Тела можно разделить на три категории:

Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла известной длины, определяемые двумя заголовками: Content-Type и Content-Length.
Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла неизвестной длины, разбитого на небольшие части (chunks) с заголовком Transfer-Encoding (en-US), значением которого является chunked.
Многоресурсные тела (Multiple-resource bodies), состоящие из многокомпонентного тела, каждая часть которого содержит свой сегмент информации. Они относительно редки.

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

Заголовки, в отличие от тел, не сжимаются.
Заголовки, которые зачастую практически совпадают у идущих подряд сообщений, приходится передавать по отдельности.
Мультиплексность невозможна. Приходится открывать соединение для каждого сообщения, а тёплые (warm) соединения TCP эффективнее холодных (cold).

HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки.

Несколько потоков можно объединять друг с другом — такой процесс называется мультиплексированием — что позволяет более эффективно использовать TCP-соединения.

Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

Сообщения HTTP играют ключевую роль в использовании HTTP; они имеют простую структуру и хорошо расширяемы. Механизм фреймов в HTTP/2 добавляет ещё один промежуточный уровень между синтаксисом HTTP/1.x и используемым им транспортным протоколом, не проводя фундаментальных изменений: создаётся надстройка над уже зарекомендовавшими себя методами.

Last modified: 4 авг. 2022 г., by MDN contributors

какое количество считается правильным и как просканировать сайт

57425 2

How-to

– Читать 6 минут

Прочитать позже

АУДИТ САЙТА — ССЫЛКИ

Инструкцию одобрила
SEO-специалист в CF. Digital

Елена Жгутова

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

Содержание:

Что такое GET-параметры
Какое количество параметров GET считается правильным
Как просканировать сайт и определить количество GET-параметров
Заключение

Что такое GET-параметры

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

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

GET-запрос состоит из домена, адреса страницы и параметров, которые следуют после знака «?». Формат одного параметра выглядит так: «ключ=объяснение». Такой вид имеет весь запрос:

http://site.ru/index.php?name=Катя&surname=Иванова

где name — первый параметр, а surname — второй параметр.

Этот же запрос в формате РНР:

<?php
echo ‘Имя: ‘ . $_GET[‘name’] . ‘<br />’;
echo ‘Фамилия: ‘ . $_GET[‘surname’] . ‘<br />’;
?>,

Или так:

<?php
if(isset($_GET['name'])) {
    echo $_GET['surname'];
}
?>,

где параметр if определяет условие: если существует параметр name, пусть он выведется на экран.

В результате браузер выдаст такую информацию:

Имя: Катя
Фамилия: Иванова

При передаче личной информации нет надобности использовать GET запрос и параметры по причине отсутствия конфиденциальности. Информация с адресной строки открыта для пользователей.

Применение такого запроса имеет смысл в случае потребности сохранить, отправить ссылку. Для передачи секретной информации лучше использовать запрос типа POST. Страницы, запросы на которые передаются параметром GET, всегда имеют статичный вид.

Какое количество параметров GET считается правильным

Один запрос включает несколько параметров GET. Их количество не ограничено протоколом http. Лимиты в размере запроса есть со стороны сервера и браузера. У каждого из них есть свой максимальный размер для приема/передачи данных. Если длина превысит этот лимит, запрос будет урезан.

Не существует конкретной максимальной величины GET-запроса. Один сервер может принимать максимум 8 Кб, а другой — 16 Кб. Средний размер запроса колеблется в пределах 512-1024 Кб.

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

При использовании человекопонятных URL (ЧПУ) передача нескольких параметров GET выполняется в скрытом формате. Чтобы увидеть запрос полностью, необходимо на время отключить ЧПУ.

Как просканировать сайт и определить количество GET-параметров

С помощью Аудита сайта Serpstat можно проверить, на каких URL вашего сайта много GET-параметров.

Создайте проект для сайта в сервисе:

В настройках перед началом сканирования выберите количество страниц, которые робот должен проверить:

После окончания сканирования перейдите на вкладку Все проверки. Если робот обнаружит такую ошибку, то вы увидите это в отчете:

Хотите узнать, как с помощью Serpstat найти и исправить технические ошибки на сайте?

Заказывайте бесплатную персональную демонстрацию сервиса, и наши специалисты вам все расскажут! 😉

Оставить заявку!

Заключение

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

Протокол http не ограничивает размер GET-запросов, но у каждого браузера и сервера существует лимит передачи данных. Рекомендуется использовать в среднем 512-1024 Кб или максимум 5 параметров для создания одного запроса.

Задавайте вопросы в комментариях или пишите в техподдержку.:) А также вступайте в чат любителей Серпстатить и подписывайтесь на наш канал в Telegram.

Сэкономьте время на изучении Serpstat

Хотите получить персональную демонстрацию сервиса, тестовый период или эффективные кейсы использования Serpstat?

Оставьте заявку и мы свяжемся с вами 😉

Оцените статью по 5-бальной шкале

4.64 из 5 на основе 11 оценок

Нашли ошибку? Выделите её и нажмите Ctrl + Enter, чтобы сообщить нам.

Как сделать запрос к API?

API InSales позволяет работать с бэк-офисом магазина, используя HTTP-запросы. При помощи API можно получать, добавлять, изменять и удалять информацию о различных объектах (например, товарах, категориях, дополнительных полях и т.д.)

Предполагается, что работа с API организована на внешнем сервере (НЕ на сервере платформы), который отправляет к серверу платформы запросы определенного типа. Для удобства в этой статье будет рассмотрена отправка запросов при помощи приложения Postman. В качестве альтернативы можно использовать Advanced REST Client.

Все доступные запросы в форматах XML и JSON описаны на api. insales.ru. Типовые запросы в формате XML с более подробным описанием можно найти на api.insales.ru.

Ограничения
Авторизация
Общие принципы
Примеры XML-запросов
Примеры JSON-запросов
Возможные коды ответов сервера

Ограничения

На платформе присутствует ограничение в 500 запросов к API в течение 5 минут. Время рассчитывается с момента первого запроса в серии. Количество выполненных запросов в текущем промежутке времени передается в HTTP-заголовке API-Usage-Limit (например, API-Usage-Limit: 1/500).

При достижении лимита доступ к API ограничивается до окончания текущих 5 минут. При этом в HTTP-заголовке Retry-After передается время в секундах до восстановления доступа.

Авторизация

Для отправки запросов к API необходимо создать ключ доступа.

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

Для создания ключа доступа нужно в бэк-офисе перейти в раздел «Приложения» → «Разработчикам» и нажать кнопку «Создать новый ключ доступа». При необходимости можно указать его название.

Далее в статье мы будем использовать созданные логин (идентификатор) и пароль. Их можно указывать как в адресе запроса:

https://логин:пароль@shop-47483-27.myinsales.ru/admin/orders.xml

Так и в виде HTTP-заголовка Authorization:

Authorization: Basic ZGlnaXRhbC1nb29kczpjNTFjOTA3MDdhMTNjZTNmZmYyMTNhZmJiNWNkMTI3MA==

Вместо shop-47483-27.myinsales.ru необходимо использовать технический или обычный домен вашего магазина. Его можно взять, например, из строки «Пример URL» около выданного ключа доступа.

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

API InSales принимает POST, GET, PUT и DELETE-запросы в зависимости от выполняемого действия. Тип и адрес запроса для требуемого действия можно найти на api.insales.ru.

Текст самого запроса должен соответствовать формату XML или JSON. В зависимости от формата меняется адрес запроса и значение HTTP-заголовка Content-Type.

Для XML необходим Content-Type: application/xml

А для JSON — Content-Type: application/json

На скриншоте программы Postman показан выбранный тип запроса, адрес и заголовки. После нажатия кнопки Send появится ответ сервера InSales.

Примеры XML-запросов

Рассмотрим GET-запрос к товару с id 143570988. Такой запрос не требует передачи серверу каких-либо параметров. В качестве адреса необходимо указать https://логин:пароль@shop-47483-27.myinsales.ru/admin/products/143570988.xml

В ответ сервер пришлёт всю доступную информацию об этом товаре.

PUT-запрос служит для обновления данных выбранного объекта. Для обновления названия того же товара с id 143570988 потребуется отправить запрос с телом

<?xml version=»1.0″ encoding=»UTF-8″?>
<product>
<title>Новое название</title>
</product>

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

Примеры JSON-запросов

Запросы в формате JSON отличаются адресом и заголовком Content-Type.

GET-запрос отправляется на адрес https://логин:пароль@shop-47483-27.myinsales.ru/admin/products/143570988.json . Ответ, соответственно, также будет этом формате.

Тело PUT-запроса на обновление названия товара выглядит следующим образом:

{

«product»: {

«title»: «Новое название»

}

Возможные коды ответов сервера

200 — штатный ответ на операцию; означает, что никаких ошибок не возникло
201 — в некоторых случаях при создании объектов может вернуться этот код; по смыслу не отличается от кода 200
400 — некорректный HTTP-запрос, сервер не смог его обработать
401 — не удалось авторизоваться (необходимо проверить логин и пароль)
403 — нет прав для данной операции (необходимо проверить настройки прав для приложения)
404 — запрашиваемый объект не найден (возможно, его уже удалили или указан неверный id объекта)
500 — внутренняя ошибка сервера (возможно, вы некорректно сформировали запрос или что-то сломалось на нашей стороне; необходимо обратиться в тех поддержку)
503 — превышен лимит запросов к API
504 — сервер не смог обработать ваш запрос за 50 секунд и прервал его выполнение (возможно, вы пытаетесь получить слишком много данных за один запрос)

Отправить Get, Post, Удалить и поставить запрос с симуляцией почтальона

Теги: postMan

Отправить Get, Post, Удалить и поставить запрос с симуляцией почтальона

Есть много симуляции, включая тестовые спокойные веб-службы, включая тестовые спокойные веб-сервис, но про-тесты, но про тест, но

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

Скачать

postman：https://www.getpostman.com/apps

2. Аналоговый запрос на отправку (запросы заголовков будут объяснены позже, запросы здесь запрашиваются восстановленными API)

Получить запрос:

Пост запрос

Поставьте запрос (похоже на запись запроса)

Удалить запрос

Мы можем видеть, что должны быть установлены заголовки и тело,Заголовок в основном для хранения информации Cookie

Тело в основном используется для хранения некоторых постов или поставленных, таких как username = «xxxx» и пароль = «124» — это данные NSData изображения для загрузки, Get и Delete, не нужно устанавливать эти два элемента.

1. О заголовках детали можно увидеть https://www.cnblogs.com/mylanguage/p/5689879.html

Резюмирован следующим образом

Существуют следующие типы кодирования о собственности типа Content:

MultiPArp / Form-data: Вы можете загружать такие файлы, как двоичные данные, или вы можете загрузить пару ориентированной на таблице, просто наконец-то преобразовать в сообщение;

X-www-form-urlencoded: только загрузка клавишных значений, а пары значения ключа разнесены.

Какой тип отправленного данных требуетсяContent-Type устанавливается на соответствующий тип данных, если вы устанавливаете его на приложение / JSON при отправке данных JSON, установите его наImage / JPEG и т. Д.

2. О теле

Есть 4 варианта в организме:form-data、x-www-form-urlencoded、raw、binary

a。form-data：Вы можете загружать значения ключей или загружать файлы. Когда загруженное поле является файлом, появится тип CONTENT, чтобы проиллюстрировать тип файла, вы можете загрузить несколько файлов.

b.x-www-form-urlencoded:Данные в форме будут преобразованы в ключевое значение, например, имя = Java & Agn = 2, только загружено пары значения ключа

c.raw：Вы можете загружать текст, JSON, XML, HTML и т. Д.

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

Спасибо за просмотр, если недостаточно или неправильно приветствуется.

Интеллектуальная рекомендация

Как ссылаться на файлы * .jar, * .aar и .so в Android Studio

Ссылка на файл .jar При создании нового проекта Android Studio уже поддерживает ссылку на файлы jar по умолчанию из-за следующего предложения: Итак, чтобы процитировать файл .jar, просто скопируйте па…

Модуль NGINX HTTP_RANDOM_INDEX_MODULE / Случайная домашняя страница (по умолчанию)

Во-первых, введение 1. Компилировать вариант —with-http_random_index_module 2, Роль: Состояние клиента Nginx Во-вторых, синтаксис конфигурации В-третьих, конфигурация В-четвертых, чек (нет файла linu…

Python цифровой водяной знак (изображение и PDF документ)

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

BFMe x Longfeng Group объединяет усилия

Гонконг, 27 октября 2018 года / PRNewswire / -Longfeng Group и трансграничная платформа электронной коммерции BFMe совместно организовали пресс-конференцию в отеле Royal Plaza в Монг-Коке в 2 часа дня. ..

Как войти в двойную часть учебника Guitar Pro

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

Несколько часто используемых макетов страниц

Предисловие Веб -макет является первым шагом в разработке веб -страницы Front -End. Это самая основная часть и очень важная часть. Макет заключается в создании общей структуры веб -страницы. Хороший м…

Сухие товары | Dubbo Community Developer Day Office Sharing

Здравствуйте, все хорошо, я маленький стек монахов. Вчера — 26 октября 2019 года, мне повезло участвовать в «Дня разработчика Dubbo Community», проводимым Али в Чэнду. Это событие собирает…

Проблема пространства имен нестандартного плагина Jquery

Недавно в проекте использовались jquery и DWR. Когда эти две платформы используются вместе, возникают конфликты. Решение простое. Добавьте пространство имен в jquery, например: var $ j = jQuery.noConf…

Intellij связан с местным хранилищем Maven

File->Settings->Maven ———————————————— File->other Settings->Settings for New Project…

Java_linklist — это предварительная реализация

1. Создайте класс узла 2. Создайте класс linklisttestest …

HTTP методы для создания RESTful сервисов

HTTP глаголы составляют основную часть «единого интерфейса», ограничивающего и предоставляющего возможность осуществлять действия над существительным-ресурсом. Основными или наиболее часто используемыми HTTP глаголами (или методами, как их иногда называют) являются POST, GET, PUT, и DELETE. Они соответствуют операциям создания, чтения, обновления и удаления (или в совокупности — CRUD). Есть еще и другие глаголы, но они используются реже. Из реже используемых методов выделяются OPTIONS и HEAD

Ниже приведена сводная таблица рекомендаций по возвращению значений при использовании основных HTTP глаголов в сочетании с ресурсами URI:

Ниже приводится более подробное обсуждение основных методов HTTP. Используйте навигацию по вкладкам для получения дополнительных сведений об интересуемом HTTP методе.

HTTP метод GET используется для получения (или чтения) представления ресурса. В случае „удачного” (или не содержащего ошибок) адреса, GET возвращается представление ресурса в формате XML или JSON в сочетании с кодом состояния HTTP 200 (OK). В случае наличия ошибок обычно возвращается код 404 (NOT FOUND) или 400 (BAD REQUEST).

В соответствии спецификации HTTP, GET (так же как и HEAD) запросы используются только для чтения данных, не изменя их. Таким образом, при соблюдении данного соглашения, они считаются безопасными. То есть они могут использоваться без риска изменения данных, вне зависимости от того, один раз данные были получены, или же 10, или ни разу вовсе. GET (а также HEAD) запросы являются идемпотентными (тождественными), что подразумевает получение идентичных данных при использовании одних и тех же запросов (как при единичном обращении, так и при многократном).

Не стоит использовать GET для небезопасных операций над данными, при данном запросе они не должны быть модифицированы.

Примеры:

GET http://www.example.com/customers/12345
GET http://www.example.com/customers/12345/orders
GET http://www.example.com/buckets/sample

Метод PUT обычно используется для предоставления возможности обновления ресурса. Тело запроса при отправке PUT-запроса к существующему ресурсу URI должно содержать обновленные данные оригинального ресурса (полностью, или только обновляемую часть).

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

Для создания новых экземпляров ресурса предпочтительнее использование POST запроса. В данном случае, при создании экземпляра будет предоставлен корректный идентификатор экземпляра ресурса в возвращённых данных об экземпляре.

При успешном обновлении посредством выполнения PUT запроса возвращается код 200 (или 204 если не был передан какой-либо контент в теле ответа). Если PUT используется для создания экземпляра — обычно возвращают HTTP код 201 при успешном создании. Возвращать данные в ответ на запрос необязательно. Также не обязательно возвращать ссылку на экземпляр ресурса посредством заголовка `Location` по причине того, что клиент и так обладает идентификатором экземпляра ресурса.

PUT не безопасная операция, так как вследствие её выполнения происходит модификация (или создание) экземпляров ресурса на стороне сервера, но этот метод идемпотентен. Другими словами, создание или обновление ресурса посредством отправки PUT запроса — ресурс не исчезнет, будет располагаться там же, где и был при первом обращении, а также, многократное выполнение одного и того же PUT запроса не изменит общего состояния системы (за исключением первого раза, но это обычно опускают из рассмотрения)

Если PUT запрос используется для увеличения счётчика просмотра конкретного ресурса — данный запрос уже не считается идемпотентным. Иногда такое происходит и считается достаточным задокументировать тот факт, что вызов не идемпотентен. Однако строго рекомендуется выдерживать идемпотентность PUT запроса.

Примеры:

PUT http://www.example.com/customers/12345
PUT http://www.example.com/customers/12345/orders/98765
PUT http://www.example.com/buckets/secret_stuff

PATCH запрос используется для **модификации** ресурса. PATCH запрос должен содержать только изменяемые данные ресурса, а не все его данные.

Это напимнает работу PUT запроса, но в теле запроса содержится набор инструкций описывающих как должен быть изменён ресурс, расположенный на сервере, для формирования новой версии. Это означает, что тело PATCH запроса должно содержать не просто изменения ресурса, а представлять из себя описание на языке внесения изменений (patch language) таких как JSON Patch или XML Patch.

PATCH запрос ни является безопасным, ни идемпотентным. Однако PATСH запрос может быть сформирован таким образом чтобы быть идемпотентным, что в свою очередь помогает предотвратить негативные последствия от коллизий между двумя PATCH запросами к одному и тому же ресурсу в один и тот же промежуток времени. Коллизии нескольких PATCH запросов могут быть более опасными чем коллизии PUT запросов, потому что некоторым форматам изменеий необходимо выполняться от известной базовой-точки или ресурс будет поврежден. Клиенты, использующие такой тип внесения изменений, должны использовать условный запрос на проверку изменения ресурса с момента последнего доступа клиента к нему. Например клиент может использовать ETag в заголовке If-Match в самом PATСH запросе.

Примеры:

PATCH http://www.example.com/customers/12345
PATCH http://www.example.com/customers/12345/orders/98765
PATCH http://www.example.com/buckets/secret_stuff

POST запрос наиболее часто используется для создания новых ресурсов. На практике он используется для создания вложенных ресурсов. Другими словами, при создании нового ресурса, POST запрос отправляется к родительскому ресурсу и, таким образом, сервис берет на себя ответственность на установление связи создаваемого ресурса с родительским ресурсом, назначение новому ресурсу ID и т.п.

При успешном создании ресурса возвращается HTTP код 201, а также в заголовке `Location` передается адрес созданного ресурса.

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

Примеры:

POST http://www.example.com/customers
POST http://www.example.com/customers/12345/orders

DELETE запрос крайне прост для понимания. Он используется для удаления ресурса, идентифицированного конкретным URI (ID).

При успешном удалении возвращается 200 (OK) код HTTP, совместно с телом ответа, содержащим данные удалённого ресурса (отрицательно сказывается на экономии трафика) или завернутые ответы (Смотрите «Возвращаемые данные»). Также возможно использование HTTP кода 204 (NO CONTENT) без тела ответа.

Согласно спецификации HTTP, DELETE запрос идемпотентен. Если вы выполняете DELETE запрос к ресурсу, он удаляется. Повторный DELETE запрос к ресурсу закончится также: ресурс удалён. Если DELETE запрос используется для декремента счётчика, DELETE запрос не является идемпотентным. Используйте POST для неидемпотентных операций.

Тем не менее, существует предостережение об идемпотентности DELETE. Повторный DELETE запрос к ресурсу часто сопровождается 404 (NOT FOUND) кодом HTTP по причине того, что ресурс уже удалён (например из базы данных) и более не доступен. Это делает DELETE операцию не идемпотентной, но это общепринятый компромисс на тот случай, если ресурс был удалён из базы данных, а не помечен, как удалённый.

Примеры:

DELETE http://www.example.com/customers/12345
DELETE http://www.example.com/customers/12345/orders
DELETE http://www.example.com/bucket/sample

Взаимодействие браузера и сервера на примере GET и POST запросов. Обработка форм.

23 Январь, 2014 — 02:30

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

Если вы уже хорошо разбираетесь в каталогах Денвера, то можете создать любой PHP-файл в удобной для вас директории и приступить непосредственно к написанию кода. Для тех, кто еще не уверен в своих силах, советую поступить следующим образом: на виртуальном диске с Денвером (обычно это Z) в папке home создайте папку lessons. Далее, в этой папке создайте еще одну папку – www. Это ваша рабочая папка проекта, которая будет доступна из строки адреса браузера. Перезагрузите Денвер, чтобы созданный хост прописался в системе. Наконец, в папке www создайте файл index.php. Это и будет основной файл с вашим кодом.

Содержание файла index.php:

Как видите – это обычная HTML-разметка, однако мы назвали файл index.php, а это значит, что теперь в документ мы можем вставлять любые инструкции на языке PHP.

Если вы теперь зайдете в браузере по адресу http://lessons/, то увидите такой результат:

Заполните поля (например: имя – Вася, год рождения – 1990) и нажмите на кнопку «отправить». Что вы видите? А ничего! Опять та же форма, только пустая. Однако не спешите огорчаться – взгляните на адресную строку браузера. Она изменилась и теперь выглядит примерно вот так:

http://lessons/index.php?user_name=Вася&user_year=1990&submit_form=отправить

А это значит, что сервер все-таки получил ваши данные!

Давайте теперь разберемся.

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

<form action="index.php" method="GET"  >

Атрибут action отвечает за адрес получателя отправляемых данных. В нашем случае форма отправляется на тот же адрес, т.е. на lessons/index.php.

Особое внимание заслуживает атрибут method, который определяет метод отправки запроса на сервер. Таких методов несколько, а наиболее распространенные (и практичные) это методы GET и POST. Сейчас нас будет интересовать метод GET.

GET-запрос означает, что данные будут передаваться на сервер непосредственно через адресную строку. Вы в этом уже убедились, отправив форму – к строке адреса добавились определенные данные. Откуда эти данные берутся? Обратите внимание на теги input в HTML-форме. У всех их присутствует атрибут name, который устанавливает имя данного поля.

При методе GET к основному адресу добавляется символ «?» (знак вопроса), чтобы сервер понимал, что поступили какие-то данные. После символа «?» идут непосредственно сами данные в виде имя=значение. Если таких данных несколько, то они разделяются между собой символом объединения «&». Отправьте форму с другими значениями полей и убедитесь в этом.

Ладно, данные отправились. Что дальше? Куда они ушли и что с ними делать? Вот тут и начинается самое интересное.

Пришло время научиться «ловить» и обрабатывать полученные данные. Ввиду того, что атрибут action указывает на текущий файл index.php, значит данные поступают именно сюда, поэтому в этом же файле мы и пропишем код обработки GET-запроса.

Итак, сразу же после тега <body> добавим такой PHP-код:

Сохраните файл, снова зайдите на http://lessons/, отправьте форму и – о, чудо! – что вы видите?

Только что, после отправки формы, сервер получил и обработал полученные данные и прислал в браузер свой ответ!

Рассмотрим PHP-код нашего проекта, который представляет собой условие:

if (isset($_GET['submit_form'])) {
}

Сервер проверяет, а получена ли переменная GET-запроса с именем submit_form? То есть, говоря проще, а была ли вообще отправлена форма? Если это так, то серверный php-код отправляет прямо в браузер пользователя новую HTML-разметку со своим ответом, используя для этого оператор echo. Если вы внимательно изучите написанный код-обработчик, то вам сразу все станет понятным!

Интересный же этот метод GET! Измените адресную строку, например, на такую:

http://lessons/index.php?user_name=Мое-имя&user_year=1900&submit_form=отправить

и нажмите кнопку «Ввод». Сервер снова вам ответит, приняв уже другие данные! Думаю, с этим все понятно.

Недостатки GET-метода в том, что, во-первых, есть ограничение на объем передаваемых данных, а во-вторых, этот метод является открытым и любую информацию можно перехватить. Поэтому личные данные пользователя (логин, имя, пароль и др.) никогда нельзя передавать через строку адреса.

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

Измените ваш файл, заменив в PHP-коде имена переменных $_GET на $_POST, а в форме пропишите method=»POST». Обновите страницу и снова отправьте форму. Результат будет таким же, что и при методе GET, однако адресная строка осталась без изменений, а это значит, что данные были благополучно отправлены в защищенном виде в теле самого запроса.

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

Итак,

Файл index.php:

Запустите пример и посмотрите, что происходит. Вначале запрашивается логин и пароль пользователя (в коде мы определили их как «admin» и «secret»), если все верно – мы попадаем на главную страницу сайта, если данные неверные – выводится соответствующее предупреждение.

Рассмотрим реализацию данной технологии.

Обратите внимание – весь код HTML-формы мы не выводим непосредственно, а запоминаем в переменной $form.

Будьте внимательны с кавычками! Весь HMTL-код находится внутри одинарных кавычек, поэтому его внутренние кавычки должны быть двойными. Если бы вы написали

$form = " …ваш код… ",

то внутренний код будет содержать наоборот – одинарные кавычки.

Далее, в строке 27 проверяется, была ли отправлена форма (условие 1 на рис.), если нет – выводится HTML-форма, и сценарий прекращает свою работу – функция die(). Больше ничего, кроме формы в браузер не выводится.

Если данные были получены, то проверяются POST-переменные на соответствие заданным (условие 2 на рис.). Если они не совпадают, то выводится предупреждающее сообщение, HTML-форма для входа и сценарий снова прекращает работу (die()).

Если же второе условие выполняется, то скрипт пропускает все операторы else и переходит на отображение основной страницы. ( переход 3 на рис.).

Это простейший пример. Естественно, в реальных проектах таких прямых проверок не производится – логин и пароль в зашифрованном виде хранятся в файлах или базе данных. Поэтому в статье описана сама технология взаимодействия клиента и сервера на основе GET и POST запросов. Для создания полноценных приложений вам необходимо иметь твердые знания по базам данных и объектно-ориентированному программированию. Об этом – в следующих статьях.

HTTP-методов GET и POST

❮ Предыдущая Далее ❯

Что такое HTTP?

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

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

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

Методы HTTP

ПОЛУЧИТЬ
ПОЧТА
ПУТ
ГОЛОВКА
УДАЛИТЬ
ЗАПЛАТКА
ОПЦИИ
ПОДКЛЮЧЕНИЕ
ТРЕЙС

Двумя наиболее распространенными методами HTTP являются: GET и POST.

Метод GET

GET используется для запроса данных из указанного ресурс.

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

/test/demo_form.php?name1=value1&name2=value2

Некоторые примечания по запросам GET:

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

Метод POST

POST используется для отправки данных на сервер для создания/обновления ресурса.

Данные, отправленные на сервер с помощью POST, сохраняются в теле запроса HTTP-запрос:

POST /test/demo_form.php HTTP/1.1
Хост: w3schools. com

name1=value1&name2=value2

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

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

Сравнение GET и POST

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

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

Метод PUT

PUT используется для отправки данных на сервер для создания/обновления ресурса.

Разница между POST и PUT заключается в том, что запросы PUT являются идемпотентными. Что то есть вызов одного и того же запроса PUT несколько раз всегда будет давать одно и то же результат. Напротив, повторный вызов POST-запроса имеет побочные эффекты: создание одного и того же ресурса несколько раз.

Метод HEAD

HEAD почти идентичен GET, но без тела ответа.

Другими словами, если GET /users возвращает список пользователей, то HEAD /users будет сделайте тот же запрос, но не вернете список пользователей.

Запросы HEAD полезны для проверки того, что вернет запрос GET до на самом деле делает запрос GET — например, перед загрузкой большого файла или ответа тело.

Метод DELETE

Метод DELETE удаляет указанный ресурс.

Метод PATCH

Метод PATCH используется для применения частичных изменений к ресурсу.

Метод OPTIONS

Метод OPTIONS описывает параметры связи для цели ресурс.

Метод CONNECT

Метод CONNECT используется для запуска двусторонней связи (туннеля) с запрошенный ресурс.

Метод TRACE

Метод TRACE используется для выполнения обратной проверки сообщения, которая проверяет путь к целевому ресурсу (полезно для целей отладки).

❮ Предыдущий Далее ❯

NEW

Мы только что запустили
Видео W3Schools

Узнать

COLOR PICKER

КОД ИГРЫ

Играть в игру

Top1s Примеры HTML

FORUM | О

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

Авторское право 1999-2022 по данным Refsnes. Все права защищены.
W3Schools использует W3.CSS.

C.4.

DICOM PS3.4 2016b — Спецификации класса обслуживания

C.4.3 Операция C-GET

SCU некоторых классов SOP класса службы запроса/получения могут генерировать запросы с использованием операции C-GET, как описано в PS3.7. Операция C-GET позволяет объекту приложения инструктировать другой объект приложения о передаче сохраненных экземпляров SOP инициирующему объекту приложения с использованием операции C-STORE. Поддержка службы C-GET должна быть согласована во время установления ассоциации как SCU, так и SCP C-GET, чтобы операция C-GET выполнялась через ассоциацию. Подоперации C-STORE должны выполняться в той же ассоциации, что и операция C-GET. Следовательно, SCP класса обслуживания запроса/получения служит SCU класса обслуживания хранилища.

Примечание

Объект приложения, который получает сохраненные экземпляры SOP, всегда является инициатором операции C-GET.

Запрос C-GET может быть выполнен на любом уровне модели запроса/получения информации. Однако передача сохраненных экземпляров SOP не может выполняться на этом уровне. Уровень, на котором выполняется передача, зависит от класса SOP.

C.4.3.1 Параметры сервиса C-GET

C.4.3.1.1 UID класса SOP

UID класса SOP идентифицирует информационную модель запроса/получения, для которой должен выполняться C-GET. Поддержка UID класса SOP подразумевается UID абстрактного синтаксиса контекста представления, используемого этой операцией C-GET.

C.4.3.1.2 Приоритет

Атрибут Priority определяет запрошенный приоритет операции C-GET и соответствующих подопераций C-STORE по отношению к другим операциям DIMSE, выполняемым тем же SCP.

От SCP не требуется обработка приоритетных запросов. Независимо от того, поддерживает ли SCP приоритетную обработку, и значение различных уровней приоритета должно быть указано в заявлении о соответствии SCP. Один и тот же приоритет должен использоваться для всех подопераций C-STORE.

C.4.3.1.3 Идентификатор

Запрос C-GET должен содержать идентификатор. Ответ C-GET должен условно содержать идентификатор, как требуется в Разделе C.4.3.1.3.2.

Примечание

Идентификатор указан как U в определении примитива C-GET в PS3.7, но он специально предназначен для использования с этой службой.

C.4.3.1.3.1 Структура идентификатора запроса

Идентификатор в запросе C-GET должен содержать:

Query/Retrieve Level (0008,0052), который определяет уровень поиска
Уникальные ключевые атрибуты, которые могут включать идентификатор пациента (0010,0020), UID экземпляра исследования (0020,000D), UID экземпляра серии (0020,000E) и UID экземпляра SOP (0008,0018)
Условно представление запроса/получения атрибутов (0008,0053). Этот атрибут может быть включен, если расширенное преобразование многокадрового изображения было принято во время расширенного согласования ассоциации. В противном случае он не должен быть включен.

Определенный набор символов (0008,0005) должен присутствовать, если идентификатор пациента (0010,0020) использует набор символов, отличный от репертуара символов по умолчанию.

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

Примечание

В нереляционном поведении может быть получено более одного объекта, если уровень запроса/получения — ИЗОБРАЖЕНИЕ, СЕРИЯ или ИССЛЕДОВАНИЕ, с использованием списка совпадений UID, но для идентификатора пациента (0010,0020) может быть указано только значение совпадения одного значения (0010,0020). .

C.4.3.1.3.2 Структура идентификатора ответа

Список UID неудачных экземпляров SOP (0008,0058) указывает список UID экземпляров SOP подоперации C-STORE, для которых эта операция C-GET не удалась. Идентификатор в ответе C-GET должен условно содержать список UID неудачных экземпляров SOP (0008,0058) на основе ответа C-GET. Если ни одна из подопераций C-STORE не завершилась неудачно, список UID экземпляров сбойных SOP (0008,0058) отсутствует, и, следовательно, в ответе C-GET не должен быть отправлен набор данных.

Определенный набор символов (0008,0005) не должен присутствовать.

Идентификатор в ответе C-GET со статусом:

Отмена, Сбой, Отказ или Предупреждение должны содержать атрибут списка UID экземпляра СОП с ошибкой
.
Ожидание не должно содержать Атрибут списка UID неудачных экземпляров SOP (без набора данных)

C.

В таблице C.4-3 определены конкретные значения кода состояния, которые могут быть возвращены в ответе C-GET. Общие значения кода состояния и поля, относящиеся к значениям кода состояния, определены в PS3.7.

Таблица C.4-3. Значения состояния ответа C-GET

Состояние службы	Дополнительное значение	Коды состояния	Связанные поля
Ошибка	Отказано: нет ресурсов — невозможно подсчитать количество совпадений	А701	(0000,0902)
	Отказано: нет ресурсов — невозможно выполнить подоперации	А702	(0000,1021) (0000,1022) (0000,1023)
	Идентификатор не соответствует SOP Class	А900	(0000,0901) (0000,0902)
	Невозможно обработать	Сххх	(0000,0901) (0000,0902)
Отменить	Подоперации прекращены из-за индикации отмены	ФЭ00	(0000,1020) (0000,1021) (0000,1022) (0000,1023)
Предупреждение	Подоперации завершены — один или несколько сбоев или предупреждений	B000	(0000,1021) (0000,1022) (0000,1023)
Успех	Подоперации завершены — нет сбоев или предупреждений	0000	(0000,1021) (0000,1022) (0000,1023)
В ожидании	Подоперации продолжаются	ФФ00	(0000,1020) (0000,1021) (0000,1022) (0000,1023)

C.

Включение количества оставшихся подопераций зависит от статуса в ответе C-GET. Количество оставшихся подопераций указывает количество оставшихся подопераций C-STORE, необходимых для завершения операции C-GET.

Ответ C-GET со статусом:

Ожидание должно содержать количество оставшихся подопераций, атрибут
.
Отменено может содержать количество оставшихся подопераций Атрибут
Предупреждение, сбой или успех не должны содержать атрибут числа оставшихся подопераций.

C.4.3.1.6 Количество завершенных подопераций

Включение числа завершенных подопераций зависит от статуса в ответе C-GET. Число завершенных подопераций указывает количество успешно завершенных подопераций C-STORE, сгенерированных запрошенной передачей.

Ответ C-GET со статусом:

Ожидание должно содержать атрибут количества завершенных подопераций
.
Отменено, Предупреждение, Сбой или Успех может содержать атрибут количества завершенных подопераций
.

C.4.3.1.7 Количество невыполненных подопераций

Включение числа невыполненных подопераций зависит от статуса в ответе C-GET. Количество невыполненных подопераций указывает количество подопераций C-STORE, сгенерированных запрошенной передачей, которые завершились сбоем.

Ответ C-GET со статусом:

Ожидание должно содержать количество невыполненных подопераций, атрибут 9. 0003
Отменено, Предупреждение, Сбой или Успех может содержать атрибут количества неудачных подопераций
.

C.4.3.1.8 Количество подопераций предупреждения

Включение количества подопераций предупреждения зависит от статуса в ответе C-GET. Количество подопераций предупреждения указывает количество подопераций C-STORE, сгенерированных запрошенной передачей, которая имела статус предупреждения.

Ответ C-GET со статусом:

Ожидание должно содержать атрибут количества подопераций предупреждения
.
Отменено, Предупреждение, Сбой или Успех может содержать атрибут Количество подопераций предупреждения

DICOM PS3.4 2016b — Спецификации класса обслуживания

Отправить HTTP-запрос — контакт (C)

Это задание отправляет HTTP-запрос на внешний сервер.

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

Идентификатор контакта
Идентификатор группы
Идентификатор сообщения
Нажатые ссылки
Значения атрибутов

Используйте это задание для отправки информации об активности контактов на внешний сервер. (Если вы хотите отправить информацию об активности системного пользователя на внешний сервер, используйте: Отправить HTTP-запрос — Системный пользователь (S).)

Поддерживаются методы GET и POST. Если вы создаете запрос POST, вы можете добавить в запрос дополнительные сложные параметры в формате XML, JSON или x-www-urlencoded. Эти параметры могут включать заполнители Mapp Engage.

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

.0003	Отправляет HTTP-запрос каждый раз при получении ответа. Ответ — это сообщение электронной почты, которое не доходит до контакта. Сообщение либо сортируется во время отправки, либо отклоняется принимающим агентом MTA. Например, запрос включает идентификатор контакта, идентификатор сообщения и тип ответа.
Отправлено одиночное сообщение (C)	Отправить HTTP-запрос (C)	Отправляет HTTP-запрос каждый раз при отправке одного сообщения. Например, запрос включает идентификатор контакта, идентификатор отдельного сообщения и время отправки. Эта автоматизация используется для отслеживания отправки отдельных сообщений. С помощью параметра «Журнал ответов» вы можете определить, была ли отправка одиночного сообщения успешной или произошла ошибка.
Данные профиля изменены (C)	Отправить HTTP-запрос (C)	Отправляет HTTP-запрос при каждом обновлении профиля получателя. Запрос включает новые данные профиля. Вы можете отправлять стандартные атрибуты Mapp Engage, настраиваемые атрибуты или атрибуты участников с HTTP-запросом.
Нажата ссылка на сообщение (C)	Отправить HTTP-запрос (C)	Отправляет HTTP-запрос каждый раз, когда получатель щелкает ссылку в сообщении. Запрос может включать в себя различные типы информации. Например: Контактный идентификатор Идентификатор сообщения ID LINK Время события
. HTTP-запрос (C)	Отправляет HTTP-запрос каждый раз, когда получатель открывает сообщение. Запрос может включать в себя различные типы информации. Например: Contact ID Message ID Time of the event

Name	Displays the name of the automation that определяется в окне Редактировать событие .
Описание	Отображает описание автоматизации, определенной в Окно редактирования события .
Событие	Отображает событие, определенное в окне Редактировать событие . Каждый раз, когда происходит это событие, Engage выполняет зависимое задание.
Задание	Определяет задание. Engage автоматически выполняет это задание каждый раз, когда происходит событие. Список всех доступных заданий см. в разделе «Все доступные задания, основанные на событиях».

В этой области определяются конкретные параметры задания.

Установка	Описание
. Пример: https://website.com/linkclicks?
Метод	Определяет метод запроса GET или POST.
Кодировка	Определяет кодировку символов значений в запросе. Эта кодировка должна быть способна передавать специальные символы выбранного языка.
Параметры	Эта область добавляет в окно новые поля параметров. Параметры добавляют в запрос практически любую информацию в виде параметров Query/URL. Это значение может быть данными из Mapp Engage или информацией из события. Вы можете добавить до 10 дополнительных параметров. Поле параметров: Добавляет дополнительные параметры строки запроса к URL-адресу запроса. Имена параметров могут быть определены произвольно, но они должны начинаться с http_. Примеры: http_opentimestamp или http_linkURL. Выбор типа значения: Заданное значение: Во второе поле можно ввести любое значение. Выбранная кодировка должна поддерживать символы в значении. Event Value: Когда установлен флажок Use Event Parameter, появляется раскрывающийся список. Параметры в раскрывающемся списке показывают значения событий, которые могут быть включены в запрос. Доступные параметры зависят от события и работают только с запросами GET. Поле значения: определяет значение, которое Mapp Engage передает в запросе. Это значение может быть статическим, атрибутом Mapp Engage или информацией из события. Стандартные атрибуты: используйте следующий формат: ${ecm:urlEncode(user[‘Email’])} Пользовательские атрибуты: используйте следующий формат: ${ecm:urlEncode(user[ ‘Электронная почта’])} Атрибуты участника: Используйте следующий формат: ${ecm:urlEncode(user[‘Email’])} Связанные данные: Используйте следующий формат: ${ecx:related(‘rdSetName’, ‘keyToSearch’)[‘columnName’]}
9000	Это поле доступно для запросов POST. Вы можете выбрать один из следующих параметров:
Content Value	Определяет дополнительные комплексные параметры для запроса. Этот параметр может включать заполнители Mapp Engage.
Запись безопасности передачи	Определяет запись безопасности передачи, которую Mapp Engage использует для запроса. Дополнительные сведения см. в разделе Параметры учетных данных.
Контакт	Выбирает идентификатор контакта для передачи в HTTP-запросе. Установите флажок «Использовать параметр события», чтобы передать идентификатор контакта из события в HTTP-запросе (доступно не для всех событий).
Идентификатор группы	Выбирает идентификатор группы для передачи в HTTP-запросе. Установите флажок «Использовать параметр события», чтобы передать идентификатор группы из события в HTTP-запросе (доступно не для всех событий).
Идентификатор сообщения	Выбирает идентификатор сообщения для передачи в HTTP-запросе. Установите флажок «Использовать параметр события», чтобы передать идентификатор сообщения из события в HTTP-запросе (доступно не для всех событий).
Идентификатор ссылки	Выбирает идентификатор ссылки для передачи в HTTP-запросе. Установите флажок Использовать параметр события, чтобы передать ссылку с события в HTTP-запросе (доступно не для всех событий).
Журнал ответов	Определяет, регистрируются ли запросы, ошибки и ответы сервера. С помощью параметра «Журнал ответов» вы можете определить, была ли отправка одиночного сообщения успешной или произошла ошибка.

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

Доступны следующие действия:

curl — Как использовать

curl / Документы / Инструмент / Man Page

Имя

curl — передача URL-адреса

Краткий обзор

curl [параметры / URL-адреса]

Описание

curl — это инструмент для передачи данных с сервера или на сервер. Он поддерживает следующие протоколы: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP. , SMTPS, TELNET, TFTP, WS и WSS. Команда предназначена для работы без взаимодействия с пользователем.

curl предлагает множество полезных трюков, таких как поддержка прокси, аутентификация пользователя, загрузка FTP, публикация HTTP, соединения SSL, файлы cookie, возобновление передачи файлов и многое другое. Как вы увидите ниже, от количества функций у вас закружится голова.

curl использует libcurl для всех функций, связанных с переносом. Подробности смотрите в libcurl(3).

URL-адрес

Синтаксис URL-адреса зависит от протокола. Подробное описание вы найдете в RFC 3986.

Вы можете указать несколько URL-адресов или частей URL-адресов, записав наборы частей в фигурных скобках и заключив URL-адрес в кавычки, как показано ниже:

"http://сайт.{один,два,три}.com"

или вы можете получить последовательности буквенно-цифровых серий, используя [] как в:

"ftp://ftp.example.com/file[1-100].txt"

"ftp://ftp.example.com/file[001-100].txt" (с ведущими нулями)

"ftp://ftp.example.com/file[az].txt"

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

"http://example.com/archive[1996-1999]/vol[1-4]/part{a,b,c}.html"

В командной строке можно указать любое количество URL-адресов. Они будут получены последовательно в указанном порядке. Вы можете указать параметры командной строки и URL-адреса в любом порядке в командной строке.

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

"http://example.com/file[1-100:10].txt"

"http://example.com/file[az:2].txt"

При использовании последовательностей [] или {} при вызове из командной строки вам, вероятно, придется заключать полный URL-адрес в двойные кавычки, чтобы оболочка не мешала ему. Это также относится к другим специальным символам, таким как, например, ‘&’, ‘?’ а также ‘*’.

Укажите индекс зоны IPv6 в URL-адресе с экранированным знаком процента и именем интерфейса. Как в

"http://[fe80::3%25eth0]/"

Если вы укажете URL-адрес без префикса protocol://, curl попытается угадать, какой протокол вам может понадобиться. Затем по умолчанию будет использоваться HTTP, но попробуйте другие протоколы на основе часто используемых префиксов имени хоста. Например, для имен хостов, начинающихся с «ftp». curl предположит, что вы хотите использовать FTP.

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

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

Вывод

Если не указано иное, curl записывает полученные данные в стандартный вывод. Вместо этого можно указать сохранить эти данные в локальный файл, используя параметры —output или —remote-name. Если curl получает несколько URL-адресов для передачи в командной строке, ему также требуется несколько вариантов того, где их сохранить.

curl не анализирует или иным образом не «понимает» содержимое, которое он получает или записывает в качестве вывода. Он не выполняет кодирование или декодирование, если только это явно не запрошено с помощью специальных параметров командной строки.

Протоколы

curl поддерживает многочисленные протоколы, или в терминах URL: схемы. Ваша конкретная сборка может не поддерживать их все.

ДИКТ

Позволяет искать слова в онлайн-словарях.

ФАЙЛ

Чтение или запись локальных файлов. curl не поддерживает удаленный доступ к URL-адресу file://, но при работе в Microsoft Windows будет работать собственный подход UNC.

FTP(S)

curl поддерживает протокол передачи файлов с множеством настроек и рычагов. С использованием или без использования TLS.

СУССУЛЬ(Ы)

Получить файлы.

HTTP(S)

curl поддерживает HTTP с многочисленными опциями и вариациями. Он может использовать HTTP версии 0.9, 1. 0, 1.1, 2 и 3 в зависимости от параметров сборки и правильных параметров командной строки.

IMAP(S)

Используя протокол чтения почты, curl может «загружать» электронные письма для вас. С использованием или без использования TLS.

LDAP(S)

curl может выполнять для вас поиск в каталогах с TLS или без него.

МКТТ

curl поддерживает MQTT версии 3. Загрузка через MQTT означает «подписаться» на тему, а загрузка/публикация — «публикацию» в теме. MQTT через TLS не поддерживается (пока).

POP3(S)

Загрузка с сервера pop3 означает получение почты. С использованием или без использования TLS.

RTMP(S)

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

РТСП

curl поддерживает загрузку RTSP 1.0.

SCP

curl поддерживает передачу SSH версии 2 scp.

SFTP

curl поддерживает SFTP (проект 5) через SSH версии 2.

SMB(S)

curl поддерживает SMB версии 1 для загрузки и выгрузки.

SMTP(S)

Загрузка содержимого на SMTP-сервер означает отправку электронного письма. С TLS или без.

ТЕЛНЕТ

Указание curl получить URL-адрес telnet запускает интерактивный сеанс, в котором он отправляет то, что читает на стандартный ввод, и выводит то, что отправляет сервер.

ТТФП

curl может выполнять загрузку и выгрузку по TFTP.

Индикатор выполнения

curl обычно отображает индикатор выполнения во время операций, показывающий объем переданных данных, скорость передачи и расчетное оставшееся время и т. д. Индикатор выполнения отображает количество байтов, а скорости указаны в байтах в секунду. Суффиксы (k, M, G, T, P) основаны на 1024. Например 1к это 1024 байта. 1М это 1048576 байт.

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

Если вам нужен счетчик выполнения для HTTP-запросов POST или PUT, вам необходимо перенаправить вывод ответа в файл, используя перенаправление оболочки (>), —output или подобное.

Это не относится к FTP-загрузке, так как эта операция не выдает никаких ответных данных на терминал.

Если вы предпочитаете индикатор прогресса вместо обычного счетчика, —progress-bar вам в помощь. Вы также можете полностью отключить индикатор прогресса с помощью параметра —silent.

Опции

Опции начинаются с одного или двух дефисов. Многие параметры требуют дополнительного значения рядом с ними.

Краткая форма параметров с одним тире, например -d, может использоваться с пробелом между ним и его значением или без него, хотя рекомендуется использовать пробел. Длинная форма с двойным тире, например —data, требует пробела между ней и ее значением.

Опции короткой версии, не требующие дополнительных значений, можно использовать сразу рядом друг с другом, например, можно указать все опции -O, -L и -v сразу как -OLv.

Как правило, все логические параметры включаются параметром —option и снова отключаются параметром —no-option. То есть вы используете то же имя параметра, но добавляете к нему префикс «no-». Однако в этом списке мы в основном перечисляем и показываем только их версию —option.

—abstract-unix-сокет <путь>

(HTTP) Подключение через абстрактный сокет домена Unix вместо использования сети. Примечание: netstat показывает путь абстрактного сокета с префиксом ‘@’, однако аргумент не должен иметь этот начальный символ.

Пример:

curl --abstract-unix-socket путь к сокету https://example.com

См. также —unix-socket. Добавлено в 7.53.0.

—alt-svc <имя файла>

(HTTPS) Этот параметр включает синтаксический анализатор alt-svc в curl. Если имя файла указывает на существующий файл кэша alt-svc, он будет использоваться. После завершения передачи кэш будет снова сохранен в файл с именем, если оно было изменено.

Укажите имя файла «» (нулевой длины), чтобы избежать загрузки/сохранения и заставить curl обрабатывать только кеш в памяти.

Если эта опция используется несколько раз, curl загрузит содержимое из всех файлов, но последний будет использоваться для сохранения.

Пример:

curl --alt-svc svc.txt https://example.com

См. также —resolve и —connect-to. Добавлено в 7.64.1.

—anyauth

(HTTP) Приказывает curl самостоятельно определить метод аутентификации и использовать наиболее безопасный из них, который, как утверждает удаленный сайт, поддерживает. Это делается путем сначала выполнения запроса и проверки заголовков ответов, что может вызвать дополнительный сетевой цикл. Это используется вместо установки определенного метода аутентификации, который вы можете сделать с помощью —basic, —digest, —ntlm и —negotiate.

Использование —anyauth не рекомендуется, если вы выполняете загрузку со стандартного ввода, так как может потребоваться отправка данных дважды, а затем клиент должен иметь возможность перемотки назад. Если при загрузке со стандартного ввода возникнет необходимость, операция загрузки завершится ошибкой.

Используется вместе с -u, —user.

Пример:

curl --anyauth --user me:pwd https://example.com

См. также —proxy-anyauth, —basic и —digest.

-а, —добавлять

(FTP SFTP) При использовании при загрузке это заставляет curl добавляться к целевому файлу, а не перезаписывать его. Если удаленный файл не существует, он будет создан. Обратите внимание, что этот флаг игнорируется некоторыми серверами SFTP (включая OpenSSH).

Пример:

curl --upload-file local --append ftp://example.com/

См. также -r, —range и -C, —continue-at.

—aws-sigv4 <поставщик1[:поставщик2[:регион[:сервис]]]>

Использовать аутентификацию подписи AWS V4 при передаче.

Аргумент поставщика — это строка, которая используется алгоритмом при создании исходящих заголовков проверки подлинности.

Аргумент региона — это строка, указывающая на географическую область коллекции ресурсов (код региона), если имя региона не указано в конечной точке.

Аргумент службы — это строка, указывающая на функцию, предоставляемую облаком (код службы), если имя службы не указано в конечной точке.

Пример:

curl --aws-sigv4 "aws:amz:east-2:es" --user "key:secret" https://example.com

См. также —basic и -u, —user. Добавлено в 7.75.0.

—базовый

(HTTP) Указывает curl использовать обычную HTTP-аутентификацию с удаленным хостом. Это значение по умолчанию, и этот параметр обычно не имеет смысла, если только вы не используете его для переопределения ранее установленного параметра, который задает другой метод аутентификации (например, —ntlm, —digest или —negotiate).

Используется вместе с -u, —user.

Пример:

curl -u имя:пароль --basic https://example.com

См. также —proxy-basic.

—cacert <файл>

(TLS) Указывает curl использовать указанный файл сертификата для проверки узла. Файл может содержать несколько сертификатов ЦС. Сертификаты должны быть в формате PEM. Обычно curl использует для этого файл по умолчанию, поэтому этот параметр обычно используется для изменения этого файла по умолчанию.

curl распознает переменную среды с именем ‘CURL_CA_BUNDLE’, если она установлена, и использует указанный путь как путь к пакету сертификатов ЦС. Эта опция переопределяет эту переменную.

Версия curl для Windows будет автоматически искать файл сертификатов ЦС с именем curl-ca-bundle.crt либо в том же каталоге, что и curl.exe, либо в текущем рабочем каталоге, либо в любой папке по пути. .

Если curl создан для библиотеки NSS SSL, для правильной работы этого параметра должен быть доступен модуль NSS PEM PKCS#11 (libnsspem.so).

(только для iOS и macOS) Если curl создан для безопасного транспорта, этот параметр поддерживается для обратной совместимости с другими механизмами SSL, но его не следует устанавливать. Если этот параметр не установлен, curl будет использовать сертификаты в системе и цепочке ключей пользователя для проверки узла, что является предпочтительным методом проверки цепочки сертификатов узла.

(только Schannel) Этот параметр поддерживается для Schannel в Windows 7 или более поздней версии с libcurl 7.60 или более поздней версии. Этот параметр поддерживается для обратной совместимости с другими механизмами SSL; вместо этого рекомендуется использовать хранилище корневых сертификатов Windows (по умолчанию для Schannel).

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --cacert CA-file.txt https://example.com

См. также —capath и -k, —insecure.

—capath <каталог>

(TLS) Указывает curl использовать указанный каталог сертификатов для проверки однорангового узла. Можно указать несколько путей, разделив их знаком «:» (например, «путь2:путь3:путь4»). Сертификаты должны быть в формате PEM, и если curl создан для OpenSSL, каталог должен быть обработан с помощью утилиты c_rehash, поставляемой с OpenSSL. Использование —capath может позволить curl на основе OpenSSL создавать SSL-соединения намного эффективнее, чем использование —cacert, если файл —cacert содержит много сертификатов CA.

Если эта опция установлена, значение capath по умолчанию будет игнорироваться, а если оно используется несколько раз, будет использовано последнее.

Пример:

curl --capath /local/directory https://example.com

См. также —cacert и -k, —insecure.

—сертификат-статус

(TLS) Приказывает curl проверить статус сертификата сервера с помощью расширения TLS запроса статуса сертификата (так называемого сшивания OCSP).

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

В настоящее время это реализовано только в бэкэндах OpenSSL, GnuTLS и NSS.

Пример:

curl --cert-status https://example.com

См. также —pinnedpubkey. Добавлено в 7.41.0.

—cert-type <тип>

(TLS) Сообщает curl, какой тип использует предоставленный сертификат клиента. PEM, DER, ENG и P12 являются признанными типами.

Тип по умолчанию зависит от серверной части TLS и обычно PEM, однако для Secure Transport и Schannel это P12. Если —cert является pkcs11: URI, то ENG является типом по умолчанию.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --cert-type PEM --cert файл https://example.com

См. также -E, —cert, —key и —key-type.

-E, —cert <сертификат[:пароль]>

(TLS) Указывает curl использовать указанный файл сертификата клиента при получении файла с HTTPS, FTPS или другим протоколом на основе SSL. Сертификат должен быть в формате PKCS#12 при использовании Secure Transport или в формате PEM при использовании любого другого механизма. Если необязательный пароль не указан, он будет запрошен на терминале. Обратите внимание, что этот параметр предполагает, что файл сертификата представляет собой конкатенацию закрытого ключа и сертификата клиента. См. —cert и —key, чтобы указать их независимо.

В части аргумента <сертификат> вы должны экранировать символ «:» как «\:», чтобы он не распознавался как разделитель пароля. Точно так же вы должны экранировать символ «\» как «\\» чтобы он не распознавался как управляющий символ.

Если curl создан для библиотеки NSS SSL, то эта опция может указать curl псевдоним сертификата для использования в базе данных NSS, определенной переменной среды SSL_DIR (или по умолчанию /etc/pki/nssdb). Если доступен модуль NSS PEM PKCS#11 (libnsspem.so), можно загрузить файлы PEM.

Если вы указываете путь относительно текущего каталога, вы должны добавить к пути префикс «./», чтобы избежать путаницы с псевдонимом базы данных NSS.

Если curl создан для библиотеки OpenSSL и доступен механизм pkcs11, то для указания сертификата, расположенного на устройстве PKCS#11, можно использовать URI PKCS#11 (RFC 7512). Строка, начинающаяся с «pkcs11:», будет интерпретироваться как URI PKCS#11. Если указан URI PKCS#11, параметр —engine будет установлен как «pkcs11», если он не был предоставлен, и параметр —cert-type будет установлен как «ENG», если он не был предоставлен.

(только для iOS и macOS) Если curl создан для безопасного транспорта, то строка сертификата может быть либо именем сертификата/закрытого ключа в системе или цепочке ключей пользователя, либо путем к сертификату в кодировке PKCS#12 и закрытый ключ. Если вы хотите использовать файл из текущего каталога, поставьте перед ним префикс «./», чтобы избежать путаницы с псевдонимом.

(только Schannel) Клиентские сертификаты должны быть указаны выражением пути к хранилищу сертификатов. (Загрузка PFX не поддерживается; вы можете сначала импортировать его в магазин). Вы можете использовать «<расположение магазина>\<имя магазина>\<отпечаток пальца>» для ссылки на сертификат в хранилище системных сертификатов, например, «CurrentUser\MY\9″.34a7ac6f8a5d579285a74fa61e19f23ddfe8d7a». Отпечаток обычно представляет собой шестнадцатеричную строку SHA-1, которую можно увидеть в сведениях о сертификате. Поддерживаются следующие расположения хранилищ: CurrentUser, LocalMachine, CurrentService, Services, CurrentUserGroupPolicy, LocalMachineGroupPolicy, LocalMachineEnterprise.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --cert certfile --key keyfile https://example.com

См. также —cert-type, —key и —key-type.

—ciphers <список шифров>

(TLS) Указывает, какие шифры использовать в соединении. В списке шифров должны быть указаны допустимые шифры. Ознакомьтесь с подробностями списка шифров SSL по этому URL-адресу:

https://curl.se/docs/ssl-ciphers.html

Если этот параметр используется несколько раз, будет использован последний.

Пример:

curl --ciphers ECDHE-ECDSA-AES256-CCM8 https://example.com

См. также —tlsv1.3.

—сжатый-SSH

(SCP SFTP) Включает встроенное сжатие SSH. Это просьба, а не приказ; сервер может это сделать, а может и нет.

Пример:

curl --compressed-ssh sftp://example.com/

См. также —сжатый. Добавлено в 7.56.0.

—сжатый

(HTTP) Запросить сжатый ответ, используя один из алгоритмов, поддерживаемых curl, и автоматически распаковать содержимое. Заголовки не изменяются.

Если эта опция используется и сервер отправляет неподдерживаемую кодировку, curl сообщит об ошибке. Это просьба, а не приказ; сервер может или не может доставлять данные в сжатом виде.

Пример:

curl --сжатый https://example.com

См. также —compressed-ssh.

-K, —config <файл>

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

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

Если параметр содержит пробелы (или начинается с : или =), параметр должен быть заключен в кавычки. В двойных кавычках доступны следующие escape-последовательности: \\, \», \t, \n, \r и \v. Обратная косая черта, предшествующая любой другой букве, игнорируется.

Если первый столбец строки конфигурации представляет собой символ «#», остальная часть строки будет рассматриваться как комментарий.

Запишите только один параметр на физическую строку в файле конфигурации.

Укажите имя файла для —config как ‘-‘, чтобы curl прочитал файл со стандартного ввода.

Обратите внимание: чтобы иметь возможность указать URL-адрес в файле конфигурации, вам необходимо указать его с помощью параметра —url, а не просто написать URL-адрес в отдельной строке. Итак, это может выглядеть примерно так:

URL = «https://curl. se/docs/»

# --- Пример файла ---
# это комментарий
URL = "example.com"
вывод = "curlhere.html"
пользовательский агент = "суперагент/1.0"

# и получить еще один URL
URL = "example.com/docs/manpage.html"
-О
реферер = "http://nowhereatall.example.com/"
# --- Конец файла примера ---

Когда curl вызывается, он (если не используется —disable) проверяет файл конфигурации по умолчанию и использует его, если он найден, даже если используется —config. Файл конфигурации по умолчанию проверяется в следующих местах в указанном порядке:

1) «$CURL_HOME/.curlrc»

2) «$XDG_CONFIG_HOME/.curlrc» (добавлено в 7.73.0)

3) «$HOME/.curlrc»

4) Windows: «%USERPROFILE%\.curlrc»

5) Windows: «%APPDATA%\.curlrc»

6) Windows: «%USERPROFILE%\данные приложения\.curlrc»

7) Не-Windows: используйте getpwuid, чтобы найти домашний каталог

8) В Windows, если он не находит файла .curlrc в описанной выше последовательности, он проверяет наличие файла в том же каталоге, в котором находится исполняемый файл curl.

В Windows для каждого местоположения проверяются два имени файла: .curlrc и _curlrc, предпочтение отдается первому. Старые версии Windows проверяли только _curlrc.

Эту опцию можно использовать несколько раз для загрузки нескольких файлов конфигурации.

Пример:

curl --config файл.txt https://example.com

См. также -q, —disable.

—connect-timeout <доли секунды>

Максимальное время в секундах, в течение которого вы разрешаете подключение curl. Это ограничивает только фазу подключения, поэтому, если curl подключается в течение заданного периода, он будет продолжаться, а если нет, то завершится. Начиная с версии 7.32.0, эта опция принимает десятичные значения.

Если эта опция используется несколько раз, будет использована последняя.

Примеры:

curl --connect-timeout 20 https://example.com
curl --connect-timeout 3.14 https://example.com

См. также -m, —max-time.

—connect-to

Для запроса к данной паре HOST1:PORT1 вместо этого подключитесь к HOST2:PORT2. Эта опция подходит для направления запросов на определенный сервер, например. на определенном узле кластера в кластере серверов. Эта опция используется только для установления сетевого соединения. Это НЕ влияет на имя хоста/порт, которые используются для TLS/SSL (например, SNI, проверка сертификата) или для протоколов приложений. «HOST1» и «PORT1» могут быть пустой строкой, означающей «любой хост/порт». «HOST2» и «PORT2» также могут быть пустой строкой, что означает «использовать исходный хост/порт запроса».

«Хост», указанный в этой опции, сравнивается как строка, поэтому он должен совпадать с именем, используемым в URL-адресе запроса. Это может быть либо цифра, например «127.0.0.1», либо полное имя хоста, например «example.org».

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

Пример:

curl --connect-to example.com:443:example.net:8443 https://example.com

См. также —resolve и -H, —header. Добавлено в 7. 49.0.

-C, —continue-в <смещении>

Продолжить/возобновить предыдущую передачу файла с заданным смещением. Заданное смещение — это точное количество байтов, которые будут пропущены, считая от начала исходного файла до его передачи в место назначения. При использовании с загрузками команда FTP-сервера SIZE не будет использоваться curl.

Используйте «-C-«, чтобы заставить curl автоматически определять, где/как возобновить передачу. Затем он использует данные выходные/входные файлы, чтобы выяснить это.

Если эта опция используется несколько раз, будет использована последняя.

Примеры:

завиток -C - https://example.com
завиток -C 400 https://example.com

См. также -r, —range.

-c, —cookie-jar <имя файла>

(HTTP) Укажите, в какой файл curl будет записывать все файлы cookie после завершения операции. Curl записывает все файлы cookie из своего хранилища файлов cookie в памяти в указанный файл в конце операций. Если файлы cookie неизвестны, данные не будут записаны. Файл будет записан с использованием формата файлов cookie Netscape. Если вы зададите имя файла с одним дефисом, «-«, файлы cookie будут записываться в стандартный вывод.

Этот параметр командной строки активирует механизм файлов cookie, который делает запись curl и использует файлы cookie. Другой способ активировать его — использовать параметр —cookie.

Если файл cookie не может быть создан или записан в него, вся операция curl не завершится ошибкой или даже четко сообщит об ошибке. Использование —verbose приведет к отображению предупреждения, но это единственная видимая обратная связь, которую вы получите об этой, возможно, смертельной ситуации.

Если эта опция используется несколько раз, будет использовано последнее указанное имя файла.

Примеры:

curl -c store-here.txt https://example.com
curl -c store-here.txt -b читать эти https://example.com

См. также -b, —cookie.

-b, —cookie <данные|имя файла>

(HTTP) Передать данные на HTTP-сервер в заголовке Cookie. Предположительно, это данные, ранее полученные от сервера в строке «Set-Cookie:». Данные должны быть в формате «ИМЯ1=ЗНАЧЕНИЕ1; ИМЯ2=ЗНАЧ2». Это заставляет curl явно использовать заголовок cookie с этим содержимым во всех исходящих запросах. Если из-за аутентификации, последующих перенаправлений или чего-то подобного выполняется несколько запросов, все они получат этот файл cookie.

Если в аргументе не используется символ ‘=’, вместо этого он рассматривается как имя файла, из которого считываются ранее сохраненные файлы cookie. Этот параметр также активирует механизм файлов cookie, который будет записывать входящие файлы cookie с помощью curl, что может быть удобно, если вы используете это в сочетании с параметром —location или выполняете несколько передач URL-адресов в одном и том же вызове. Если имя файла равно минусу («-«), curl вместо этого будет считывать содержимое со стандартного ввода.

Формат файла для чтения файлов cookie должен быть простым заголовком HTTP (стиль Set-Cookie) или форматом файла cookie Netscape/Mozilla.

Файл, указанный с —cookie, используется только в качестве входных данных. Никакие файлы cookie не будут записаны в файл. Чтобы сохранить файлы cookie, используйте параметр —cookie-jar.

Если вы используете формат файла Set-Cookie и не указываете домен, то cookie не отправляется, так как домен никогда не будет совпадать. Чтобы решить эту проблему, установите домен в строке Set-Cookie (при этом будут включены поддомены) или, что предпочтительнее: используйте формат Netscape.

Эту опцию можно использовать несколько раз.

Пользователи часто хотят одновременно читать файлы cookie из файла и записывать обновленные файлы cookie обратно в файл, поэтому использование —cookie и —cookie-jar в одной и той же командной строке является распространенным явлением.

Примеры:

curl -b файл cookie https://example.com
curl -b файл cookie -c файл cookie https://example.com

См. также -c, —cookie-jar и -j, —junk-session-cookies.

—создать-каталоги

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

Созданные каталоги создаются с режимом 0750 в файловых системах стиля unix.

Чтобы создать удаленные каталоги при использовании FTP или SFTP, попробуйте —ftp-create-dirs.

Пример:

curl --create-dirs --output local/dir/file https://example.com

См. также —ftp-create-dirs и —output-dir.

—create-file-mode <режим>

(SFTP SCP FILE) Когда curl используется для удаленного создания файлов с использованием одного из поддерживаемых протоколов, этот параметр позволяет пользователю установить, какой «режим» следует установить для файла во время создания вместо значения по умолчанию 0644.

Эта опция принимает восьмеричное число в качестве аргумента.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --create-file-mode 0777 -T локальный файл sftp://example.com/new

См. также —ftp-create-dirs. Добавлено в 7.75.0.

—crlf

(FTP SMTP) Преобразование LF в CRLF при загрузке. Полезно для MVS (OS/390).

(SMTP добавлен в 7.40.0)

Пример:

curl --crlf -T файл ftp://example.com/

См. также -B, —use-ascii.

—crlfile <файл>

(TLS) Предоставьте файл в формате PEM со списком отозванных сертификатов, в котором могут быть указаны одноранговые сертификаты, которые следует считать отозванными.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --crlfile rejects.txt https://example.com

См. также —cacert и —capath.

—curves <список алгоритмов>

(TLS) Указывает curl запрашивать определенные кривые для использования во время установления сеанса SSL в соответствии с RFC 8422, 5.1. Можно указать несколько алгоритмов, разделив их знаком «:» (например, «X25519:P-521″). Аналогично параметр доступен в утилитах «openssl s_client/s_server».

—curves позволяет curl на основе OpenSSL устанавливать SSL-соединения точно с кривой (EC), запрошенной клиентом, избегая непрозрачных согласований клиент/сервер.

Если этот параметр установлен, список кривых по умолчанию, встроенный в openssl, будет игнорироваться.

Пример:

curl --curves X25519 https://example.com

См. также —шифры. Добавлено в 7.73.0.

—data-ascii <данные>

(HTTP) Это просто псевдоним для -d, —data.

Пример:

curl --data-ascii @file https://example.com

См. также —data-binary, —data-raw и —data-urlencode.

—data-binary <данные>

(HTTP) Это отправляет данные точно так, как указано, без какой-либо дополнительной обработки.

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

Как и —data, тип содержимого по умолчанию, отправляемый на сервер, — application/x-www-form-urlencoded. Если вы хотите, чтобы данные обрабатывались сервером как произвольные двоичные данные, установите тип содержимого в поток октетов: -H «Тип содержимого: приложение/поток октетов».

Если этот параметр используется несколько раз, те, что следуют за первым, будут добавлять данные, как описано в параметрах -d, —data.

Пример:

curl --data-binary @filename https://example.com

См. также —data-ascii.

—data-raw <данные>

(HTTP) Это отправляет данные аналогично —data, но без специальной интерпретации символа @.

Примеры:

curl --data-raw "привет" https://example.com
curl --data-raw "@at@at@" https://example.com

См. также -d, —data. Добавлено в 7.43.0.

—data-urlencode <данные>

(HTTP) Это отправляет данные, как и другие параметры —data, за исключением того, что это выполняет URL-кодирование.

Чтобы быть совместимым с CGI, часть должна начинаться с имени, за которым следует разделитель и спецификация содержимого. Часть может быть передана в curl с использованием одного из следующих синтаксисов:

содержание

Это заставит curl URL-кодировать содержимое и передать его дальше. Просто будьте осторожны, чтобы содержимое не содержало никаких символов = или @, так как это приведет к тому, что синтаксис будет соответствовать одному из других случаев ниже!

= содержание

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

имя=содержание

Это заставит curl URL-кодировать часть содержимого и передать ее дальше. Обратите внимание, что часть имени уже должна быть закодирована в URL-адресе.

@имя файла

Это заставит curl загружать данные из данного файла (включая любые новые строки), URL-кодировать эти данные и передавать их в POST.

имя@имя файла

Это заставит curl загружать данные из данного файла (включая любые новые строки), URL-кодировать эти данные и передавать их в POST. К части имени добавляется знак равенства, в результате чего получается name=urlencoded-file-content. Обратите внимание, что имя уже должно быть закодировано в URL.

Примеры:

curl --data-urlencode name=val https://example.com
curl --data-urlencode = закодировать это https://example.com
curl --data-urlencode имя@файл https://example.com
curl --data-urlencode @fileonly https://example.com

См. также -d, —data и —data-raw.

-d, —data <данные>

(HTTP MQTT) Отправляет указанные данные в запросе POST на HTTP-сервер точно так же, как это делает браузер, когда пользователь заполняет HTML-форму и нажимает кнопку отправки. Это заставит curl передать данные на сервер, используя тип содержимого application/x-www-form-urlencoded. Сравните с -F, —form.

—data-raw почти такой же, но не имеет специальной интерпретации символа @. Чтобы опубликовать чисто двоичные данные, вы должны вместо этого использовать параметр —data-binary. Для URL-кодирования значения поля формы вы можете использовать —data-urlencode.

Если какой-либо из этих параметров используется более одного раза в одной и той же командной строке, указанные фрагменты данных будут объединены разделительным символом &. Таким образом, использование ‘-d name=daniel -d skill=lousy’ приведет к созданию фрагмента сообщения, похожего на ‘name=daniel&skill=lousy’.

Если вы начинаете данные с буквы @, остальное должно быть именем файла для чтения данных, или — если вы хотите, чтобы curl читал данные из стандартного ввода. Таким образом, публикация данных из файла с именем «foobar» будет выполняться с параметрами -d, —data @foobar. Когда —data сообщается о чтении из такого файла, возвращается каретка и символы новой строки удаляются. Если вы не хотите, чтобы символ @ имел специальную интерпретацию, используйте вместо него —data-raw.

Примеры:

curl -d "имя=curl" https://example. com
curl -d "name=curl" -d "tool=cmdline" https://example.com
curl -d @filename https://example.com

См. также —data-binary, —data-urlencode и —data-raw. Эта опция взаимоисключающая для -F, —form и -I, —head и -T, —upload-file.

—делегирование <УРОВЕНЬ>

(GSS/kerberos) Установите УРОВЕНЬ, чтобы указать серверу, что ему разрешено делегировать, когда речь идет об учетных данных пользователя.

нет

Запретить делегирование.

политика

Делегирует только в том случае, если в билете службы Kerberos установлен флаг OK-AS-DELEGATE, что является вопросом политики области.

всегда

Безоговорочно разрешить серверу делегировать.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --delegation "нет" https://example.com

См. также -k, —insecure и —ssl.

—дайджест

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

Если эта опция используется несколько раз, используется только первая.

Пример:

curl -u имя:пароль --digest https://example.com

См. также -u, —user, —proxy-digest и —anyauth. Эта опция взаимоисключающая для —basic и —ntlm и —negotiate.

—disable-eprt

(FTP) Скажите curl отключить использование команд EPRT и LPRT при выполнении активных передач FTP. Curl обычно всегда сначала пытается использовать EPRT, затем LPRT перед использованием PORT, но с этой опцией он сразу же будет использовать PORT. EPRT и LPRT являются расширениями исходного протокола FTP и могут работать не на всех серверах, но они обеспечивают больше функциональных возможностей лучше, чем традиционная команда PORT.

—eprt можно использовать для повторного явного включения EPRT, а —no-eprt является псевдонимом для —disable-eprt.

Если доступ к серверу осуществляется по протоколу IPv6, эта опция не будет работать, поскольку в этом случае необходим протокол EPRT.

Отключение EPRT изменяет только активное поведение. Если вы хотите переключиться в пассивный режим, вам не нужно использовать —ftp-port или принудительно использовать —ftp-pasv.

Пример:

curl --disable-eprt ftp://example.com/

См. также —disable-epsv и -P, —ftp-port.

—отключить-epsv

(FTP) Скажите curl, чтобы отключить использование команды EPSV при выполнении пассивных передач FTP. Curl обычно всегда сначала пытается использовать EPSV перед PASV, но с этой опцией он не будет пытаться использовать EPSV.

—epsv можно использовать для повторного явного включения EPSV, а —no-epsv является псевдонимом для —disable-epsv.

Если сервер является хостом IPv6, эта опция не будет иметь никакого эффекта, так как тогда необходим EPSV.

Отключение EPSV изменяет только пассивное поведение. Если вы хотите переключиться в активный режим, вам нужно использовать -P, —ftp-port.

Пример:

curl --disable-epsv ftp://example. com/

См. также —disable-eprt и -P, —ftp-port.

-q, —отключить

При использовании в качестве первого параметра в командной строке файл конфигурации curlrc не будет прочитан и использован. См. —config для получения подробной информации о пути поиска файла конфигурации по умолчанию.

Пример:

завиток -q https://example.com

См. также -K, —config.

—disallow-имя-пользователя-в-url

(HTTP) Это указывает curl выйти, если передан URL-адрес, содержащий имя пользователя. Это, вероятно, наиболее полезно, когда URL-адрес предоставляется во время выполнения или аналогично.

Пример:

curl --disallow-имя-пользователя-в-url https://example.com

См. также —proto. Добавлено в 7.61.0.

—dns-интерфейс <интерфейс>

(DNS) Скажите curl отправлять исходящие DNS-запросы через . Эта опция является аналогом —interface (которая не влияет на DNS). Предоставленная строка должна быть именем интерфейса (не адресом).

Пример:

curl --dns-интерфейс eth0 https://example.com

См. также —dns-ipv4-addr и —dns-ipv6-addr. —dns-interface требует, чтобы базовая библиотека libcurl была создана для поддержки c-ares. Добавлено в 7.33.0.

—dns-ipv4-addr <адрес>

(DNS) Скажите curl привязываться к при отправке DNS-запросов IPv4, чтобы DNS-запросы исходили с этого адреса. Аргумент должен быть одним адресом IPv4.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --dns-ipv4-addr 10.1.2.3 https://example.com

См. также —dns-interface и —dns-ipv6-addr. —dns-ipv4-addr требует, чтобы базовая библиотека libcurl была создана для поддержки c-ares. Добавлено в 7.33.0.

—dns-ipv6-addr <адрес>

(DNS) Скажите curl привязываться к при отправке DNS-запросов IPv6, чтобы DNS-запросы исходили с этого адреса. Аргумент должен быть одним адресом IPv6.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --dns-ipv6-addr 2a04:4e42::561 https://example.com

См. также —dns-interface и —dns-ipv4-addr. —dns-ipv6-addr требует, чтобы базовая библиотека libcurl была создана для поддержки c-ares. Добавлено в 7.33.0.

—dns-серверы <адреса>

Установите список DNS-серверов, которые будут использоваться вместо системного по умолчанию. Список IP-адресов должен быть разделен запятыми. Номера портов также могут быть указаны как : после каждого IP-адреса.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --dns-серверы 192.168.0.1,192.168.0.2 https://example.com

См. также —dns-interface и —dns-ipv4-addr. —dns-servers требует, чтобы базовая библиотека libcurl была создана для поддержки c-ares. Добавлено в 7.33.0.

—doh-сертификат-статус

То же, что и —cert-status, но используется для DoH (DNS-over-HTTPS).

Пример:

curl --doh-cert-status --doh-url https://doh. example https://example.com

См. также —doh-insecure. Добавлено в 7.76.0.

—doh-небезопасно

То же, что и —insecure, но используется для DoH (DNS-over-HTTPS).

Пример:

curl --doh-insecure --doh-url https://doh.example https://example.com

См. также —doh-url. Добавлено в 7.76.0.

—doh-url

Указывает, какой сервер DNS-через-HTTPS (DoH) следует использовать для разрешения имен хостов вместо использования механизма преобразования имен по умолчанию. URL-адрес должен быть HTTPS.

Некоторые параметры SSL, которые вы установили для передачи, будут применяться к DoH, поскольку поиск имени выполняется через SSL. Однако параметры проверки сертификата не наследуются и могут управляться отдельно с помощью —doh-insecure и —doh-cert-status.

Этот параметр не установлен, если в качестве URL-адреса используется пустая строка «». (Добавлено в 7.85.0)

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --doh-url https://doh.example https://example.com

См. также —doh-insecure. Добавлено в 7.62.0.

-D, —dump-header <имя файла>

(HTTP FTP) Записать полученные заголовки протокола в указанный файл. Если заголовки не получены, использование этой опции создаст пустой файл.

При использовании в FTP строки ответов FTP-сервера считаются «заголовками» и поэтому сохраняются там.

Если эта опция используется несколько раз, будет использована последняя.

Пример:

curl --dump-header store.txt https://example.com

См. также -o, —output.

—egd-file <файл>

(TLS) Устаревший параметр. Эта опция игнорируется curl, начиная с версии 7.84.0. До этого он влиял на curl только в том случае, если он был создан для использования старых версий OpenSSL.

Укажите путь к сокету Entropy Gathering Daemon. Сокет используется для заполнения механизма случайных чисел SSL-соединениями.

Пример:

curl --egd-file /random/здесь https://example.com

См. также —random-file.

—engine <имя>

(TLS) Выберите механизм шифрования OpenSSL, который будет использоваться для операций шифрования. Используйте —engine list для вывода списка поддерживаемых движков во время сборки. Обратите внимание, что не все (и, возможно, ни один) движки могут быть доступны во время выполнения.

Пример:

curl --engine аромат https://example.com

См. также —шифры и —кривые.

—etag-compare <файл>

(HTTP) Этот параметр выполняет условный HTTP-запрос для определенного ETag, считанного из заданного файла, путем отправки пользовательского заголовка If-None-Match с использованием сохраненного ETag.

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

Используйте параметр —etag-save, чтобы сначала сохранить ETag из ответа, а затем используйте этот параметр для сравнения с сохраненным ETag в последующем запросе.

Пример:

curl --etag-compare etag.txt https://example.com

См. также —etag-save и -z, —time-cond. Добавлено в 7.68.0.

—etag-save <файл>

(HTTP) Этот параметр сохраняет ETag HTTP в указанный файл. ETag — это заголовок, связанный с кэшированием, обычно возвращаемый в ответе.

Если сервер не отправляет ETag, создается пустой файл.

Пример:

curl --etag-save storetag.txt https://example.com

См. также —etag-compare. Добавлено в 7.68.0.

—expect100-timeout <секунды>

(HTTP) Максимальное время в секундах, которое вы позволяете curl ожидать ответа 100-continue, когда curl выдает заголовок Expects: 100-continue в своем запросе. По умолчанию curl будет ждать одну секунду. Эта опция принимает десятичные значения! Когда curl перестанет ждать, он продолжит работу, как если бы ответ был получен.

Пример:

curl --expect100-timeout 2.5 -T файл https://example.com

См. также —connect-timeout. Добавлено в 7.47.0.

—сбой-рано

Сбой и выход при первой обнаруженной ошибке передачи.

Когда curl используется для выполнения нескольких передач в командной строке, он будет пытаться работать с каждым заданным URL-адресом, один за другим. По умолчанию он игнорирует ошибки, если указано больше URL-адресов, и успех последнего URL-адреса будет определять возврат кода ошибки curl. Так что ранние неудачи будут «спрятаны» последующими удачными переносами.

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

Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, —next.

Этот параметр не подразумевает -f, —fail, что приводит к сбою передачи из-за кода состояния HTTP сервера. Вы можете комбинировать эти два параметра, однако обратите внимание, —fail не является глобальным и поэтому содержится в -:, —next.

Пример:

curl --fail-early https://example.com https://two.example

См. также -f, —fail и —fail-with-body. Добавлено в 7.52.0.

—сбой с телом

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

Это альтернатива —fail, которая приводит к сбою curl при тех же обстоятельствах, но без сохранения содержимого.

Пример:

curl --fail-with-body https://example.com

См. также -f, —fail. Эта опция взаимоисключающая для -f, —fail. Добавлено в 7.76.0.

-f, —сбой

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

Этот метод не является отказоустойчивым, и бывают случаи, когда неуспешные коды ответов проскальзывают, особенно при аутентификации (коды ответов 401 и 407).

Пример:

curl --fail https://example.com

См. также —fail-with-body. Эта опция взаимоисключающая для —fail-with-body.

—фальстарт

(TLS) Сообщает curl использовать фальстарт во время рукопожатия TLS. Ложный запуск — это режим, в котором клиент TLS начинает отправлять данные приложения до проверки сообщения Finished сервера, тем самым экономя время на передачу туда и обратно при выполнении полного рукопожатия.

В настоящее время это реализовано только в серверных частях NSS и Secure Transport (в iOS 7.0 или более поздней версии или OS X 10. 9 или более поздней версии).

Пример:

curl --false-start https://example.com

См. также —tcp-fastopen. Добавлено в 7.42.0.

—form-escape

(HTTP) Указывает curl передавать имена составных полей формы и файлов, используя обратную косую черту вместо процентного кодирования.

Пример:

curl --form-escape -F 'field\name=curl' -F 'file=@load"this' https://example.com

См. также -F, —form. Добавлено в 7.81.0.

—form-string <имя=строка>

(HTTP SMTP IMAP) Аналогично —form, за исключением того, что строка значения для именованного параметра используется буквально. Начальные символы ‘@’ и ‘<', а также строка ';type=' в значении не имеют особого значения. Используйте это вместо --form, если существует вероятность того, что строковое значение может случайно вызвать функции '@' или '<' -F, --form.

Пример:

curl --form-string "данные" https://example.com

См. также -F, —form.

-F, —form <имя=содержание>

(HTTP SMTP IMAP) Для семейства протоколов HTTP это позволяет curl эмулировать заполненную форму, в которой пользователь нажал кнопку отправки. Это приводит к закручиванию данных POST с использованием Content-Type multipart/form-data в соответствии с RFC 2388.

Для протоколов SMTP и IMAP это средство составления составного почтового сообщения для передачи.

Это позволяет загружать двоичные файлы и т. д. Чтобы заставить часть «содержимое» быть файлом, поставьте перед именем файла знак @. Чтобы просто получить часть содержимого из файла, добавьте к имени файла префикс символа <. Разница между @ и < заключается в том, что @ заставляет файл прикрепляться к сообщению как загрузку файла, а < создает текстовое поле и просто получает содержимое для этого текстового поля из файла.

Укажите curl читать содержимое из стандартного ввода вместо файла, используя — as имя файла. Это касается как конструкций @, так и <. Когда используется стандартный ввод, содержимое сначала буферизуется в памяти с помощью curl, чтобы определить его размер и разрешить повторную отправку. Определение данных части из именованного нестандартного файла (например, именованного канала или подобного), к сожалению, не подлежит буферизации и будет эффективно считываться во время передачи; поскольку полный размер неизвестен до начала передачи, такие данные отправляются порциями по HTTP и отклоняются IMAP.

Пример: отправить изображение на HTTP-сервер, где «профиль» — это имя поля формы, в которое будет вводиться файл Portrait.jpg:

curl -F [email protected] https://example.com/upload.cgi

Пример: отправьте на сервер свое имя и размер обуви в двух текстовых полях:

curl -F имя=Джон -F размер обуви=11 https://example.com/

Пример: отправьте свое эссе в текстовом поле на сервер. Отправьте его как обычное текстовое поле, но получите его содержимое из локального файла:

curl -F "story= Вы также можете указать curl, какой Content-Type использовать, используя 'type=', примерно так:
curl -F "web=@index. html;type=text/html" example.com

или
curl -F "name=daniel;type=text/foo" example.com

Вы также можете явно изменить поле имени части загрузки файла, установив имя_файла=, например:
curl -F "file=@localfile;filename=nameinpost" example.com

Если имя файла/путь содержит ',' или ';', оно должно быть заключено в двойные кавычки, например:
curl -F "file=@\"local,file\";filename=\"name;in;post\"" example.com

или
curl -F 'file=@"local,file";filename="name;in;post"' example.com

Обратите внимание: если имя файла или путь заключены в двойные кавычки, любая двойная кавычка или обратная косая черта в имени файла должны быть экранированы обратной косой чертой.
Заключение также должно применяться к нефайловым данным, если они содержат точки с запятой, начальные/конечные пробелы или начальные двойные кавычки:
curl -F 'colors="красный; зеленый; синий";type=text/x-myapp' example. com

Вы можете добавить пользовательские заголовки в поле, установив headers=, например
curl -F "submit=OK;headers=\"X-submit-type: OK\"" example.com

или
curl -F "отправить=ОК;заголовки=@headerfile" example.com

Ключевое слово headers= может встречаться более одного раза, и применяются приведенные выше примечания о цитировании. Когда заголовки считываются из файла, пустые строки и строки, начинающиеся с '#', являются комментариями и игнорируются; каждый заголовок можно свернуть, разделив его на два слова и начав строку продолжения с пробела; встроенные возвраты каретки и конечные пробелы удаляются. Вот пример содержимого заголовочного файла:
# Этот файл содержит два заголовка.
X-header-1: это заголовок

# Следующий заголовок свернут.
X-заголовок-2: это
другой заголовок

Для поддержки отправки составных почтовых сообщений синтаксис расширен следующим образом:
- имя может быть опущено: знак равенства является первым символом аргумента,
- если данные начинаются с '(', это сигнализирует о начале нового составной: за ним может следовать спецификация типа содержимого
- составной элемент может быть завершен аргументом '=)'.
Пример: следующая команда отправляет SMTP-мим-сообщение, состоящее из встроенной части, в двух альтернативных форматах: обычный текст и HTML. Он прикрепляет текстовый файл:
curl -F '=(;type=multipart/alternative' \
-F '=простое текстовое сообщение' \
-F '= HTML-сообщение;type=text/html' \
-F '=)' -F '[email protected]' ... smtp://example.com

Данные могут быть закодированы для передачи с помощью encoder=. Доступные кодировки: бинарная и 8-битная, которые ничего не делают, кроме добавления соответствующего заголовка Content-Transfer-Encoding, 7-битная, которая отбрасывает только 8-битные символы с ошибкой передачи, кавычки-печатные и base64, кодирующие данные по соответствующим схемам, ограничивающие строки длина до 76 символов.
Пример: отправить составную почту с текстовым сообщением в кавычках и прикрепленным файлом base64:
curl -F '=текстовое сообщение;encoder=quoted-printable' \
-F '=@localfile;encoder=base64' . .. smtp://example.com

Дополнительные примеры и подробности см. в РУКОВОДСТВЕ.
Эту опцию можно использовать несколько раз.
Пример:
curl --form "name=curl" --form "file=@loadthis" https://example.com

См. также -d, --data, --form-string и --form-escape. Эта опция взаимоисключающая для -d, --data и -I, --head и -T, --upload-file.
--ftp-аккаунт <данные>
(FTP) Когда FTP-сервер запрашивает «данные учетной записи» после предоставления имени пользователя и пароля, эти данные отправляются с помощью команды ACCT.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --ftp-account "mr.robot" ftp://example.com/

См. также -u, --user.
--ftp-alternative-to-user <команда>
(FTP) Если аутентификация с помощью команд USER и PASS не удалась, отправьте эту команду. При подключении к защищенному транспортному серверу Tumbleweed через FTPS с использованием клиентского сертификата использование «SITE AUTH» сообщит серверу, что нужно получить имя пользователя из сертификата.
Пример:
curl --ftp-alternative-to-user "U53r" ftp://example.com

См. также --ftp-account и -u, --user.
--ftp-создать-каталоги
(FTP SFTP) Когда URL-адрес/операция FTP или SFTP использует путь, который в данный момент не существует на сервере, стандартное поведение curl — сбой. Используя эту опцию, curl вместо этого попытается создать отсутствующие каталоги.
Пример:
curl --ftp-create-dirs -T файл ftp://example.com/remote/path/file

См. также --create-dirs.
--ftp-метод <метод>
(FTP) Укажите, какой метод curl должен использовать для доступа к файлу на FTP-сервере. Аргумент метода должен быть одним из следующих вариантов:
многократный ввод
curl выполняет одну операцию CWD для каждой части пути в заданном URL-адресе. Для глубоких иерархий это означает множество команд. Вот как RFC 1738 говорит, что это должно быть сделано. Это поведение по умолчанию, но самое медленное.
ночн
curl вообще не выполняет CWD. curl сделает SIZE, RETR, STOR и т. д. и даст полный путь к серверу для всех этих команд. Это самое быстрое поведение.
однократный
curl делает один CWD с полным целевым каталогом, а затем работает с файлом "как обычно" (как в случае multicwd). Это несколько больше соответствует стандартам, чем «nocwd», но без полного штрафа «multicwd».
Примеры:
curl --ftp-method multicwd ftp://example.com/dir1/dir2/file
curl --ftp-метод nocwd ftp://example.com/dir1/dir2/file
curl --ftp-method singlecwd ftp://example.com/dir1/dir2/file

См. также -l, --list-only.
--ftp-pasv
(FTP) Использовать пассивный режим для передачи данных. Пассивное — это внутреннее поведение по умолчанию, но с помощью этой опции можно переопределить предыдущую опцию --ftp-port.
Если эта опция используется несколько раз, используется только первая. Отмена принудительного пассива на самом деле невозможна, но вместо этого вы должны снова применить правильный --ftp-port.
Пассивный режим означает, что curl сначала попытается выполнить команду EPSV, а затем PASV, если только не используется --disable-epsv.
Пример:
curl --ftp-pasv ftp://example.com/

См. также --disable-epsv.
-P, --ftp-порт <адрес>
(FTP) Меняет местами роли инициатора/слушателя по умолчанию при соединении с FTP. Эта опция заставляет curl использовать активный режим. Затем curl сообщает серверу о необходимости обратного подключения к указанному адресу и порту клиента, в то время как в пассивном режиме серверу предлагается настроить IP-адрес и порт для подключения. <адрес> должен быть одним из:
интерфейс
напр. «eth0», чтобы указать IP-адрес интерфейса, который вы хотите использовать (только для Unix)
IP-адрес
напр. «192.168.10.1», чтобы указать точный IP-адрес
имя хоста
напр. "my.host.domain" для указания машины
-
заставить curl выбрать тот же IP-адрес, который уже используется для управляющего соединения
Если эта опция используется несколько раз, будет использована последняя. Отключите использование PORT с --ftp-pasv. Отключите попытку использования команды EPRT вместо PORT с помощью --disable-eprt. EPRT на самом деле PORT++.
Вы также можете добавить ":[начало]-[конец]" справа от адреса, чтобы сообщить curl, какой диапазон портов TCP использовать. Это означает, что вы указываете диапазон портов от меньшего к большему номеру. Один номер также работает, но учтите, что это увеличивает риск сбоя, поскольку порт может быть недоступен.
Примеры:
curl -P - ftp:/example.com
curl -P eth0 ftp:/example.com
curl -P 192.168.0.2 ftp:/example.com

См. также --ftp-pasv и --disable-eprt.
--ftp-pret
(FTP) Скажите curl отправить команду PRET перед PASV (и EPSV). Некоторым FTP-серверам, в основном drftpd, требуется эта нестандартная команда для просмотра каталогов, а также загрузки и загрузки в режиме PASV.
Пример:
curl --ftp-pret ftp://example.com/

См. также -P, --ftp-port и --ftp-pasv.
--ftp-skip-pasv-ip
(FTP) Сообщите curl, чтобы он не использовал IP-адрес, который сервер предлагает в своем ответе на команду curl PASV, когда curl устанавливает соединение для передачи данных. Вместо этого curl будет повторно использовать тот же IP-адрес, который уже используется для управляющего соединения.
Начиная с версии curl 7.74.0 эта опция включена по умолчанию.
Этот параметр не действует, если вместо PASV используется PORT, EPRT или EPSV.
Пример:
curl --ftp-skip-pasv-ip ftp://example.com/

См. также --ftp-pasv.
--ftp-ssl-ccc-mode <активный/пассивный>
(FTP) Устанавливает режим CCC. Пассивный режим не инициирует завершение работы, а вместо этого ждет, пока это сделает сервер, и не будет отвечать на завершение работы с сервера. Активный режим инициирует завершение работы и ожидает ответа от сервера.
Пример:
curl --ftp-ssl-ccc-mode active --ftp-ssl-ccc ftps://example.com/

См. также --ftp-ssl-ccc.
--ftp-ssl-ccc
(FTP) Использовать CCC (Clear Command Channel) Отключает уровень SSL/TLS после аутентификации. Остальная часть связи канала управления будет незашифрованной. Это позволяет маршрутизаторам NAT отслеживать транзакцию FTP. Режим по умолчанию пассивный.
Пример:
curl --ftp-ssl-ccc ftps://example.com/

См. также --ssl и --ftp-ssl-ccc-mode.
--ftp-ssl-управление
(FTP) Требовать SSL/TLS для входа на FTP, снять флажок для передачи. Обеспечивает безопасную аутентификацию, но для повышения эффективности передает незашифрованные данные. Сбой передачи, если сервер не поддерживает SSL/TLS.
Пример:
curl --ftp-ssl-control ftp://example.com

См. также --ssl.
-G, --получить
При использовании этой опции все данные, указанные с помощью -d, --data, --data-binary или --data-urlencode, будут использоваться в запросе HTTP GET вместо запроса POST, который в противном случае использовался бы. Данные будут добавлены к URL-адресу с помощью '?' разделитель.
При использовании в сочетании с -I, --head данные POST вместо этого будут добавлены к URL-адресу с запросом HEAD.
Если эта опция используется несколько раз, используется только первая. Это связано с тем, что отмена GET не имеет смысла, но вместо этого вы должны применить альтернативный метод, который вы предпочитаете.
Примеры:
curl --получить https://example.com
curl --get -d "tool=curl" -d "age=old" https://example.com
curl --get -I -d "tool=curl" https://example.com

См. также -d, --data и -X, --request.
-г, --globoff
Эта опция отключает "парсер подстановки URL". Когда вы устанавливаете этот параметр, вы можете указать URL-адреса, содержащие буквы {}[], без того, чтобы сам curl их интерпретировал. Обратите внимание, что эти буквы не являются обычным содержимым URL-адреса, но они должны быть закодированы в соответствии со стандартом URI.
Пример:
curl -g "https://example. com/{[]}}}}"

См. также -K, --config и -q, --disable.
--happy-eyeballs-timeout-ms <миллисекунды>
Happy Eyeballs — это алгоритм, который пытается подключиться к адресам IPv4 и IPv6 для хостов с двойным стеком, давая IPv6 преимущество в указанное количество миллисекунд. Если за это время невозможно подключиться к IPv6-адресу, то параллельно делается попытка подключения к IPv4-адресу. Первое соединение, которое должно быть установлено, является тем, которое используется.
Диапазон предлагаемых полезных значений ограничен. В документе Happy Eyeballs RFC 6555 говорится: «РЕКОМЕНДУЕТСЯ, чтобы попытки подключения осуществлялись с разницей в 150–250 мс, чтобы сбалансировать человеческий фактор и нагрузку на сеть». libcurl в настоящее время по умолчанию составляет 200 мс. В Firefox и Chrome в настоящее время по умолчанию установлено значение 300 мс.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --happy-eyeballs-timeout-ms 500 https://example. com

См. также -m, --max-time и --connect-timeout. Добавлено в 7.59.0.
--haproxy-протокол
(HTTP) Отправить заголовок протокола HAProxy PROXY v1 в начале соединения. Это используется некоторыми балансировщиками нагрузки и обратными прокси-серверами для указания истинного IP-адреса и порта клиента.
Этот параметр в первую очередь полезен при отправке тестовых запросов службе, которая ожидает этот заголовок.
Пример:
curl --haproxy-протокол https://example.com

См. также -x, --proxy. Добавлено в 7.60.0.
-I, --голова
(HTTP FTP ФАЙЛ) Получить только заголовки! HTTP-серверы имеют команду HEAD, которая используется для получения только заголовка документа. При использовании с файлом FTP или FILE curl отображает только размер файла и время последнего изменения.
Пример:
завиток -I https://example.com

См. также -G, --get, -v, --verbose и --trace-ascii.
-H, --header <заголовок/@файл>
(HTTP) Дополнительный заголовок для включения в запрос при отправке HTTP на сервер. Вы можете указать любое количество дополнительных заголовков. Обратите внимание, что если вы должны добавить собственный заголовок с тем же именем, что и один из внутренних заголовков, который будет использовать curl, ваш внешний заголовок будет использоваться вместо внутреннего. Это позволяет вам делать даже более сложные вещи, чем обычно делает curl. Вы не должны заменять внутренне установленные заголовки, не зная в совершенстве, что вы делаете. Удалите внутренний заголовок, указав замену без содержания справа от двоеточия, например: -H "Host:". Если вы отправляете пользовательский заголовок без значения, его заголовок должен заканчиваться точкой с запятой, например -H "X-Custom-Header;" для отправки "X-Custom-Header:".
curl позаботится о том, чтобы каждый заголовок, который вы добавляете/заменяете, был отправлен с правильным маркером конца строки, поэтому вам не следует добавлять его как часть содержимого заголовка: не добавляйте новые строки или возврат каретки, они будут только портить вещи для вас.
Эта опция может принимать аргумент в стиле @filename, который затем добавляет заголовок для каждой строки во входном файле. Использование @- заставит curl прочитать заголовочный файл со стандартного ввода. Добавлено в 7.55.0.
Вам нужен --proxy-header для отправки пользовательских заголовков, предназначенных для прокси-сервера HTTP. Добавлено в 7.37.0.
Передача заголовка «Transfer-Encoding: chunked» при выполнении HTTP-запроса с телом запроса заставит curl отправлять данные с использованием кодирования в виде фрагментов.
ПРЕДУПРЕЖДЕНИЕ: заголовки, установленные с помощью этой опции, будут установлены во всех запросах - даже после того, как будут выполнены перенаправления, например, если указано с помощью -L, --location. Это может привести к тому, что заголовок будет отправлен на другие хосты, а не на исходный хост, поэтому конфиденциальные заголовки следует использовать с осторожностью в сочетании с последующими переадресациями.
Эту опцию можно использовать несколько раз для добавления/замены/удаления нескольких заголовков.
Примеры:
curl -H "Имя X: Джо" https://example.com
curl -H "Агент пользователя: да-пожалуйста/2000" https://example.com
curl -H "Хост:" https://example.com

См. также -A, --user-agent и -e, --referer.
-h, --help <категория>
Справка по использованию. Здесь перечислены все команды <категории>. Если аргумент не указан, curl отобразит наиболее важные аргументы командной строки. Если был указан аргумент «все», curl отобразит все доступные параметры. Если был указан аргумент «категория», curl отобразит все категории и их значения.
Пример:
curl --помогите всем

См. также -v, --verbose.
--hostpubmd5
(SFTP SCP) Передайте строку, содержащую 32 шестнадцатеричных цифры. Строка должна быть 128-битной контрольной суммой MD5 открытого ключа удаленного хоста, curl откажется от соединения с хостом, если md5sums не совпадают.
Пример:
curl --hostpubmd5 e5c1c4
40a5ab0f2034854c321a8 sftp://example. com/

См. также --hostpubsha256.
--hostpubsha256
(SFTP SCP) Передайте строку, содержащую хэш SHA256 в кодировке Base64 открытого ключа удаленного хоста. Curl откажется от соединения с хостом, если хэши не совпадут.
Пример:
curl --hostpubsha256 NDVkMTQxMGQ1ODdmMjQ3MjczYjAyOTY5MmRkMjVmNDQ= sftp://example.com/

См. также --hostpubmd5. Добавлено в 7.80.0.
--hsts <имя файла>
(HTTPS) Этот параметр включает HSTS для передачи. Если имя файла указывает на существующий файл кэша HSTS, он будет использоваться. После завершения передачи кэш будет снова сохранен в файл с именем, если оно было изменено.
Укажите имя файла "" (нулевой длины), чтобы избежать загрузки/сохранения и заставить curl обрабатывать только HSTS в памяти.
Если эта опция используется несколько раз, curl загрузит содержимое из всех файлов, но последний будет использоваться для сохранения.
Пример:
curl --hsts cache. txt https://example.com

См. также --proto. Добавлено в 7.74.0.
--http0.9
(HTTP) Сообщает curl, что все в порядке с ответом HTTP версии 0.9.
HTTP/0.9является полностью беззаголовочным ответом, и поэтому вы также можете подключиться с ним к серверам, отличным от HTTP, и все равно получить ответ, поскольку curl просто прозрачно понизит версию - если это разрешено.
Начиная с curl 7.66.0, HTTP/0.9 по умолчанию отключен.
Пример:
завиток --http0.9 https://example.com

См. также --http1.1, --http2 и --http3. Добавлено в 7.64.0.
-0, --http1.0
(HTTP) Сообщает curl использовать HTTP версии 1.0 вместо внутренней предпочтительной версии HTTP.
Пример:
завиток --http1.0 https://example.com

См. также --http0.9 и --http1.1. Эта опция взаимоисключающая для --http1.1 и --http2 и --http2-prior-knowledge и --http3.
--http1.1
(HTTP) Сообщает curl использовать HTTP версии 1. 1.
Пример:
завиток --http1.1 https://example.com

См. также -0, --http1.0 и --http0.9. Эта опция взаимоисключающая для -0, --http1.0 и --http2 и --http2-prior-knowledge и --http3. Добавлено в 7.33.0.
--http2-до-знания
(HTTP) Сообщает curl, чтобы он выполнял HTTP-запросы, отличные от TLS, с использованием HTTP/2 без обновления HTTP/1.1. Требуется предварительное знание того, что сервер сразу поддерживает HTTP/2. Запросы HTTPS по-прежнему будут выполнять HTTP/2 стандартным способом с согласованной версией протокола в рукопожатии TLS.
Пример:
curl --http2-до-знания https://example.com

См. также --http2 и --http3. --http2-prior-knowledge требует, чтобы базовая библиотека libcurl была создана для поддержки HTTP/2. Эта опция взаимоисключающая для --http1.1 и -0, --http1.0 и --http2 и --http3. Добавлено в 7.49.0.
--http2
(HTTP) Сообщает curl использовать HTTP версии 2.
Для HTTPS это означает, что curl попытается согласовать HTTP/2 в рукопожатии TLS. curl делает это по умолчанию.
Для HTTP это означает, что curl попытается обновить запрос до HTTP/2, используя заголовок запроса Upgrade:.
Когда curl использует HTTP/2 поверх HTTPS, он сам не настаивает на TLS 1.2 или выше, даже если это требуется по спецификации. Пользователь может добавить это требование к версии с --tlsv1.2.
Пример:
завиток --http2 https://example.com

См. также --http1.1 и --http3. --http2 требует, чтобы базовая библиотека libcurl была создана для поддержки HTTP/2. Эта опция взаимоисключающая для --http1.1 и -0, --http1.0 и --http2-prior-knowledge и --http3. Добавлено в 7.33.0.
--http3
(HTTP) ПРЕДУПРЕЖДЕНИЕ: этот параметр является экспериментальным. Не использовать в производстве.
Указывает curl использовать HTTP версии 3 непосредственно для хоста и номера порта, используемого в URL-адресе. Обычная транзакция HTTP/3 будет выполнена с хостом, а затем будет перенаправлена через Alt-Svc, но эта опция позволяет пользователю обойти это, когда вы знаете, что цель использует HTTP/3 на данном хосте и порту.
Этот параметр приведет к сбою curl, если соединение QUIC не может быть установлено, он не может самостоятельно вернуться к более низкой версии HTTP.
Пример:
завиток --http3 https://example.com

См. также --http1.1 и --http2. --http3 требует, чтобы базовая библиотека libcurl была создана для поддержки HTTP/3. Эта опция взаимоисключающая для --http1.1 и -0, --http1.0 и --http2 и --http2-preor-knowledge. Добавлено в 7.66.0.
--игнорировать-длину-содержимого
(FTP HTTP) Для HTTP игнорируйте заголовок Content-Length. Это особенно полезно для серверов с Apache 1.x, которые будут сообщать неверную длину содержимого для файлов размером более 2 гигабайт.
Для FTP (начиная с 7.46.0) пропустите команду RETR, чтобы определить размер перед загрузкой файла.
Этот параметр не работает для HTTP, если libcurl был создан для использования гипер.
Пример:
curl --ignore-content-length https://example.com

См. также --ftp-skip-pasv-ip.
-i, --include
Включить в вывод заголовки ответов HTTP. Заголовки ответа HTTP могут включать такие вещи, как имя сервера, файлы cookie, дату документа, версию HTTP и многое другое...
Чтобы просмотреть заголовки запроса, используйте параметр --verbose.
Пример:
завиток -i https://example.com

См. также -v, --verbose.
-k, --небезопасно
(TLS SFTP SCP) По умолчанию каждое безопасное соединение, которое создает curl, проверяется на безопасность перед передачей. Эта опция заставляет curl пропустить шаг проверки и продолжить работу без проверки.
Если этот параметр не используется для протоколов, использующих TLS, прежде чем продолжить, curl проверяет сертификат TLS сервера: что сертификат содержит правильное имя, которое соответствует имени хоста, используемому в URL-адресе, и что сертификат подписан сертификатом ЦС. присутствует в хранилище сертификатов. Дополнительную информацию см. на этом онлайн-ресурсе:
.
https://curl.se/docs/sslcerts.html

Для SFTP и SCP этот параметр заставляет curl пропускать проверку known_hosts. known_hosts — это файл, обычно хранящийся в домашнем каталоге пользователя в подкаталоге «.ssh», который содержит имена хостов и их открытые ключи.
ПРЕДУПРЕЖДЕНИЕ: использование этой опции делает передачу небезопасной.
Пример:
curl --insecure https://example.com

См. также --proxy-insecure, --cacert и --capath.
--interface <имя>
Выполнение операции с использованием указанного интерфейса. Вы можете ввести имя интерфейса, IP-адрес или имя хоста. Пример может выглядеть так:
curl --interface eth0:1 https://www.example.com/

Если этот параметр используется несколько раз, будет использован последний.
В Linux его можно использовать для указания VRF, но двоичный файл должен либо иметь CAP_NET_RAW, либо запускаться от имени пользователя root. Дополнительная информация о Linux VRF: https://www. kernel.org/doc/Documentation/networking/vrf.txt
Пример:
curl --interface eth0 https://example.com

См. также --dns-интерфейс.
-4, --ipv4
Эта опция указывает curl использовать только адреса IPv4, а не, например, пробовать IPv6.
Пример:
завиток --ipv4 https://example.com

См. также --http1.1 и --http2. Эта опция взаимоисключающая для -6, --ipv6.
-6, --ipv6
Эта опция указывает curl использовать только адреса IPv6, а не, например, пытаться использовать IPv4.
Пример:
завиток --ipv6 https://example.com

См. также --http1.1 и --http2. Эта опция взаимоисключающая для -4, --ipv4.
--json <данные>
(HTTP) Отправляет указанные данные JSON в запросе POST на HTTP-сервер. --json работает как ярлык для передачи этих трех параметров:
--данные [аргумент]
--header "Тип контента: приложение/json"
--header "Принять: приложение/json"

Нет подтверждения того, что переданные данные являются действительными JSON или что синтаксис правильный.
Если вы начинаете данные с буквы @, остальное должно быть именем файла, из которого будут считываться данные, или одним дефисом (-), если вы хотите, чтобы curl считывал данные со стандартного ввода. Таким образом, публикация данных из файла с именем «foobar» будет выполняться с помощью --json @foobar, а для чтения данных из стандартного ввода используйте --json @-.
Если этот параметр используется более одного раза в одной и той же командной строке, дополнительные фрагменты данных будут присоединены к предыдущим перед отправкой.
Заголовки, устанавливаемые этой опцией, можно, как обычно, переопределить с помощью --header.
Примеры:
curl --json '{ "напиток": "кофе" }' https://example.com
curl --json '{ "напиток":' --json ' "кофе" }' https://example.com
curl --json @prepared https://example.com
curl --json @- https://example.com < json.txt

См. также --data-binary и --data-raw. Эта опция взаимоисключающая для -F, --form и -I, --head и -T, --upload-file. Добавлено в 7.82.0.
-j, --junk-session-cookies
(HTTP) Когда curl предлагается прочитать файлы cookie из данного файла, эта опция заставит его удалить все «сеансовые файлы cookie». В основном это будет иметь тот же эффект, что и при запуске нового сеанса. Типичные браузеры всегда отбрасывают файлы cookie сеанса, когда они закрываются.
Пример:
curl --junk-session-cookies -b cookies.txt https://example.com

См. также -b, --cookie и -c, --cookie-jar.
--keepalive-time <секунды>
Этот параметр устанавливает время, в течение которого соединение должно оставаться бездействующим перед отправкой тестов проверки активности, а также время между отдельными проверками активности. В настоящее время он эффективен в операционных системах, предлагающих параметры сокета TCP_KEEPIDLE и TCP_KEEPINTVL (имеется в виду Linux, последние версии AIX, HP-UX и другие). Keepalive используются стеком TCP для обнаружения сломанных сетей при бездействующих соединениях. Количество пропущенных проверок активности перед объявлением об отключении соединения зависит от ОС и обычно равно 9.или 10. Эта опция не действует, если используется --no-keepalive.
Если эта опция используется несколько раз, будет использована последняя. Если не указано, параметр по умолчанию равен 60 секундам.
Пример:
curl --keepalive-time 20 https://example.com

См. также --no-keepalive и -m, --max-time.
--key-type <тип>
(TLS) Тип файла закрытого ключа. Укажите тип вашего --key предоставленного закрытого ключа. Поддерживаются DER, PEM и ENG. Если не указано, предполагается PEM.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --key-type DER --key здесь https://example.com

См. также --key.
--key <ключ>
(TLS SSH) Имя файла закрытого ключа. Позволяет вам указать свой закрытый ключ в этом отдельном файле. Для SSH, если он не указан, curl пробует следующие кандидаты по порядку: '~/. ssh/id_rsa', '~/.ssh/id_dsa', './id_rsa', './id_dsa'.
Если curl создан для библиотеки OpenSSL и доступен механизм pkcs11, то можно использовать URI PKCS#11 (RFC 7512) для указания закрытого ключа, расположенного на устройстве PKCS#11. Строка, начинающаяся с «pkcs11:», будет интерпретироваться как URI PKCS#11. Если указан URI PKCS#11, параметр --engine будет установлен как «pkcs11», если он не был предоставлен, и параметр --key-type будет установлен как «ENG», если он не был предоставлен.
Если curl создан для безопасного транспорта или Schannel, то этот параметр игнорируется для протоколов TLS (HTTPS и т. д.). Эти серверные части ожидают, что закрытый ключ уже присутствует в цепочке ключей или файле PKCS#12, содержащем сертификат.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --cert certificate --key здесь https://example.com

См. также --key-type и -E, --cert.
--krb <уровень>
(FTP) Включить аутентификацию и использование Kerberos. Уровень должен быть введен и должен быть одним из «чистого», «безопасного», «конфиденциального» или «личного». Если вы используете уровень, который не является одним из них, вместо этого будет использоваться «частный».
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --krb очистить ftp://example.com/

См. также --delegation и --ssl. --krb требует, чтобы базовая библиотека libcurl была создана для поддержки Kerberos.
--libcurl <файл>
Добавьте эту опцию к любой обычной командной строке curl, и вы получите исходный код C, использующий libcurl, записанный в файл, который делает то же, что и ваша операция командной строки!
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Если эта опция используется несколько раз, будет использовано последнее заданное имя файла.
Пример:
curl --libcurl client.c https://example. com

См. также -v, --verbose.
--limit-rate <скорость>
Укажите максимальную скорость передачи, которую должен использовать curl — как для скачивания, так и для выгрузки. Эта функция полезна, если у вас ограниченный канал и вы хотите, чтобы ваша передача не использовала всю пропускную способность. Чтобы сделать это медленнее, чем это было бы в противном случае.
Указанная скорость измеряется в байтах в секунду, если не добавлен суффикс. При добавлении «k» или «K» число будет считаться килобайтами, «m» или «M» — мегабайтами, а «g» или «G» — гигабайтами. Суффиксы (k, M, G, T, P) основаны на 1024. Например, 1k — это 1024. Примеры: 200K, 3m и 1G.
Логика ограничения скорости работает, усредняя скорость передачи не выше установленного порога в течение нескольких секунд.
Если вы также используете параметр --speed-limit, этот параметр будет иметь приоритет и может немного повредить ограничение скорости, чтобы сохранить работу логики ограничения скорости.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --limit-rate 100K https://example.com
curl --limit-rate 1000 https://example.com
curl --limit-rate 10M https://example.com

См. также -Y, --speed-limit и -y, --speed-time.
-l, --только список
(FTP POP3) (FTP) При отображении каталога FTP этот переключатель принудительно отображает только имя. Это особенно полезно, если пользователь хочет выполнить машинный анализ содержимого каталога FTP, поскольку обычное представление каталога не использует стандартный вид или формат. При таком использовании этот параметр вызывает отправку на сервер команды NLST вместо LIST.
Примечание. Некоторые FTP-серверы в своем ответе на NLST перечисляют только файлы; они не включают в себя подкаталоги и символические ссылки.
(POP3) При извлечении определенного сообщения электронной почты из POP3 этот переключатель заставляет выполнять команду LIST вместо RETR. Это особенно полезно, если пользователь хочет увидеть, существует ли на сервере определенный идентификатор сообщения и каков его размер.
Примечание. В сочетании с -X, --request этот параметр можно использовать для отправки команды UIDL, поэтому пользователь может использовать уникальный идентификатор электронной почты, а не его идентификатор сообщения для выполнения запроса.
Пример:
curl --только список ftp://example.com/dir/

См. также -Q, --quote и -X, --request.
--local-port <номер/диапазон>
Задайте предпочтительный номер или диапазон (FROM-TO) номеров локальных портов, которые будут использоваться для соединений. Обратите внимание, что номера портов по своей природе являются дефицитным ресурсом, который время от времени будет занят, поэтому установка слишком узкого диапазона может привести к ненужным сбоям при установке соединения.
Пример:
curl --local-port 1000-3000 https://example.com

См. также -g, --globoff.
--надежное местоположение
(HTTP) Аналогично -L, --location, но позволяет отправлять имя и пароль всем хостам, на которые сайт может перенаправляться. Это может привести или не привести к нарушению безопасности, если сайт перенаправит вас на сайт, на который вы отправите свою информацию для аутентификации (которая является открытым текстом в случае аутентификации HTTP Basic).
Пример:
curl --location-trusted -u пользователь:пароль https://example.com

См. также -u, --user.
-L, --местоположение
(HTTP) Если сервер сообщает, что запрошенная страница была перемещена в другое место (обозначается заголовком Location: и кодом ответа 3XX), эта опция заставит curl повторить запрос на новом месте. При использовании вместе с --include или -I, --head будут показаны заголовки со всех запрошенных страниц. Когда используется аутентификация, curl отправляет свои учетные данные только на исходный хост. Если редирект перенаправит curl на другой хост, он не сможет перехватить пароль пользователя и пароль. См. также --location-trusted, как это изменить. Вы можете ограничить количество последующих перенаправлений, используя параметр --max-redirs.
Когда curl следует за перенаправлением и если запрос является POST, он отправит следующий запрос с GET, если ответ HTTP был 301, 302 или 303. Если код ответа был любым другим кодом 3xx, curl будет повторно отправьте следующий запрос, используя тот же немодифицированный метод.
Вы можете указать curl не изменять POST-запросы на GET после 30-кратного ответа, используя для этого специальные параметры: --post301, --post302 и --post303.
Метод, заданный параметром --request, переопределяет метод curl, который в противном случае был бы выбран для использования.
Пример:
завиток -L https://example.com

См. также --resolve и --alt-svc.
--login-options <параметры>
(IMAP LDAP POP3 SMTP) Укажите параметры входа для использования во время проверки подлинности сервера.
Вы можете использовать параметры входа в систему, чтобы указать параметры протокола, которые могут использоваться во время аутентификации. В настоящее время только IMAP, POP3 и SMTP поддерживают параметры входа в систему. Дополнительные сведения о параметрах входа см. в RFC 2384, RFC 509.2 и проект IETF draft-earhart-url-smtp-00.txt.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --login-options 'AUTH=*' imap://example.com

См. также -u, --user. Добавлено в 7.34.0.
--mail-auth <адрес>
(SMTP) Укажите один адрес. Это будет использоваться для указания адреса аутентификации (идентификации) отправленного сообщения, которое ретранслируется на другой сервер.
Пример:
curl --mail-auth [email protected] -T mail smtp://example.com/

См. также --mail-rcpt и --mail-from.
--mail-от <адрес>
(SMTP) Укажите один адрес, с которого должна отправляться данная почта.
Пример:
curl --mail-from [email protected] -T mail smtp://example.com/

См. также --mail-rcpt и --mail-auth.
--mail-rcpt-allowfails
(SMTP) При отправке данных нескольким получателям curl по умолчанию прерывает SMTP-диалог, если хотя бы один из получателей заставляет команду RCPT TO возвращать ошибку.
Поведение по умолчанию можно изменить, передав параметр командной строки --mail-rcpt-allowfails, который заставит curl игнорировать ошибки и продолжит работу с оставшимися допустимыми получателями.
Если все получатели инициируют сбои RCPT TO и указан этот флаг, curl все равно прервет SMTP-диалог и вернет ошибку, полученную от, до последней команды RCPT TO.
Пример:
curl --mail-rcpt-allowfails --mail-rcpt [email protected] smtp://example.com

См. также --mail-rcpt. Добавлено в 7.69.0.
--mail-rcpt <адрес>
(SMTP) Укажите один адрес электронной почты, имя пользователя или имя списка рассылки. Повторите этот параметр несколько раз, чтобы отправить сообщение нескольким получателям.
При выполнении проверки адреса (команда VRFY) получатель должен быть указан как имя пользователя или имя пользователя и домен (согласно разделу 3. 5 RFC 5321). (Добавлено в 7.34.0)
При расширении списка рассылки (команда EXPN) получатель должен быть указан с использованием имени списка рассылки, например «Друзья» или «London-Office». (Добавлено в 7.34.0)
Пример:
curl --mail-rcpt [email protected] smtp://example.com

См. также --mail-rcpt-allowfails.
-М, --ручной
Руководство. Показать огромный текст справки.
Пример:
завиток --ручной

См. также -v, --verbose, --libcurl и --trace.
--max-filesize <байт>
(FTP HTTP MQTT) Укажите максимальный размер (в байтах) загружаемого файла. Если запрошенный файл больше этого значения, передача не начнется, и curl вернется с кодом выхода 63.
Можно использовать модификатор размера. Например, при добавлении «k» или «K» число будет считаться килобайтом, «m» или «M» — мегабайтом, а «g» или «G» — гигабайтом. Примеры: 200K, 3m и 1G. (Добавлено в 7.58.0)
ПРИМЕЧАНИЕ. Размер файла не всегда известен перед загрузкой, и для таких файлов эта опция не действует, даже если передаваемый файл оказывается больше заданного ограничения. Пример:
curl --max-filesize 100K https://example.com

См. также --limit-rate.
--max-redirs <число>
(HTTP) Установить максимальное количество перенаправлений. Когда используется --location, чтобы curl не выполнял слишком много перенаправлений, по умолчанию ограничение установлено на 50 перенаправлений. Установите для этого параметра значение -1, чтобы сделать его неограниченным.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --max-redirs 3 --location https://example.com

См. также -L, --location.
-m, --max-time <доли секунды>
Максимальное время в секундах, которое может занять каждая передача. Это полезно для предотвращения зависания ваших пакетных заданий в течение нескольких часов из-за медленных сетей или соединений. Начиная с версии 7.32.0, этот параметр принимает десятичные значения, но точность фактического тайм-аута будет уменьшаться по мере увеличения десятичной точности заданного тайм-аута.
Если включить повторную попытку передачи (--retry), то счетчик максимального времени сбрасывается при каждой повторной попытке передачи. Вы можете использовать --retry-max-time, чтобы ограничить время повтора.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --max-time 10 https://example.com
curl --max-time 2.92 https://example.com

См. также --connect-timeout и --retry-max-time.
--металинк
Этот параметр ранее использовался для указания ресурса металинк. Поддержка Metalink отключена в curl начиная с 7.78.0 по соображениям безопасности.
Пример:
curl --metalink файл https://example.com

См. также -Z, --parallel.
--переговоры
(HTTP) Включает аутентификацию Negotiate (SPNEGO).
Для этого параметра требуется библиотека, созданная с поддержкой GSS-API или SSPI. Используйте --version, чтобы узнать, поддерживает ли ваш curl GSS-API/SSPI или SPNEGO.
При использовании этой опции вы также должны предоставить опцию fake --user для правильной активации кода аутентификации. Отправки '-u :' достаточно, так как имя пользователя и пароль из опции --user на самом деле не используются.
Если эта опция используется несколько раз, используется только первая.
Пример:
curl --negotiate -u : https://example.com

См. также --basic, --ntlm, --anyauth и --proxy-negotiate.
--netrc-file <имя файла>
Эта опция аналогична -n, --netrc, за исключением того, что вы указываете путь (абсолютный или относительный) к файлу netrc, который должен использовать curl. Вы можете указать только один файл netrc для каждого вызова. Если указано несколько параметров --netrc-file, будет использоваться последний из них.
Будет соблюдаться параметр --netrc-Optional, если он указан.
Пример:
curl --netrc-файл netrc https://example.com

См. также -n, --netrc, -u, --user и -K, --config. Эта опция взаимоисключающая для -n, --netrc.
--netrc-необязательно
Аналогично -n, --netrc, но эта опция делает использование .netrc необязательным, а не обязательным, как это делает опция --netrc.
Пример:
curl --netrc-необязательный https://example.com

См. также --netrc-file. Эта опция взаимоисключающая для -n, --netrc.
-n, --netrc
Заставляет curl сканировать файл .netrc (_netrc в Windows) в домашнем каталоге пользователя на предмет имени для входа и пароля. Обычно это используется для FTP в Unix. При использовании с HTTP curl включит аутентификацию пользователя. Смотрите netrc(5) и ftp(1) для подробностей о формате файла. Curl не будет жаловаться, если у этого файла нет правильных разрешений (он не должен быть доступен для чтения всем или группе). Переменная среды «HOME» используется для поиска домашнего каталога.
Быстрый и простой пример того, как настроить .netrc, чтобы разрешить curl для доступа по FTP к машине host. domain.com с именем пользователя «myself» и паролем «secret», может выглядеть примерно так:
машина host.domain.com
авторизоваться
секретный пароль

Пример:
curl --netrc https://example.com

См. также --netrc-file, -K, --config и -u, --user.
-:, --следующий
Указывает curl использовать отдельную операцию для следующего URL-адреса и связанных параметров. Это позволяет вам отправлять несколько запросов URL, каждый со своими специфическими параметрами, например, такими как разные имена пользователей или настраиваемые запросы для каждого.
--next сбросит все локальные параметры, и только глобальные значения сохранятся до операции, следующей за инструкцией --next. Глобальные параметры включают -v, --verbose, --trace, --trace-ascii и --fail-early.
Например, вы можете выполнить и GET, и POST в одной командной строке:
curl www1.example.com --next -d postthis www2.example.com

Примеры:
curl https://example. com --next -d postthis www2.example.com
curl -I https://example.com --next https://example.net/

См. также -Z, --parallel и -K, --config. Добавлено в 7.36.0.
--но-альпн
(HTTPS) Отключить расширение ALPN TLS. ALPN включен по умолчанию, если libcurl был собран с библиотекой SSL, поддерживающей ALPN. ALPN используется libcurl, поддерживающим HTTP/2, для согласования поддержки HTTP/2 с сервером во время сеансов https.
Пример:
curl --no-alpn https://example.com

См. также --no-npn и --http2. --no-alpn требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Добавлено в 7.36.0.
-N, --без буфера
Отключает буферизацию выходного потока. В обычных рабочих ситуациях curl будет использовать стандартный буферизованный поток вывода, что приведет к тому, что он будет выводить данные порциями, не обязательно точно в момент поступления данных. Использование этой опции отключит эту буферизацию.
Обратите внимание, что это задокументированное инвертированное имя опции. Таким образом, вы можете использовать --buffer для принудительной буферизации.
Пример:
curl --no-buffer https://example.com

См. также -#, --progress-bar.
--нет-клоббер
При использовании в сочетании с параметрами -o, --output, -J, --remote-header-name, -O, --remote-name или --remote-name-all curl позволяет избежать перезаписи файлов, которые уже существует. Вместо этого к имени файла, который будет создан, добавляется точка и число, вплоть до имени файла.100, после чего файл не создается.
Обратите внимание, что это задокументированное инвертированное имя опции. Таким образом, вы можете использовать --clobber для принудительного затирания, даже если указано --remote-header-name или -J.
Пример:
curl --no-clobber --output local/dir/file https://example.com

См. также -o, --output и -O, --remote-name. Добавлено в 7.83.0.
--нет поддержания активности
Отключает использование сообщений проверки активности в TCP-соединении. curl в противном случае включает их по умолчанию.
Обратите внимание, что это задокументированное инвертированное имя опции. Таким образом, вы можете использовать --keepalive для обеспечения поддержки активности.
Пример:
curl --no-keepalive https://example.com

См. также --keepalive-time.
--нет-npn
(HTTPS) В curl 7.86.0 и более поздних версиях curl никогда не использует NPN.
Отключить расширение NPN TLS. NPN включен по умолчанию, если libcurl был собран с библиотекой SSL, которая поддерживает NPN. NPN используется libcurl, поддерживающим HTTP/2, для согласования поддержки HTTP/2 с сервером во время сеансов https.
Пример:
curl --no-npn https://example.com

См. также --no-alpn и --http2. --no-npn требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Добавлено в 7.36.0.
--нет счетчика прогресса
Возможность отключения вывода индикатора выполнения без отключения или иного воздействия на предупреждающие и информационные сообщения, такие как --silent.
Обратите внимание, что это задокументированное инвертированное имя опции. Таким образом, вы можете использовать --progress-meter, чтобы снова включить индикатор выполнения.
Пример:
curl --no-progress-meter -o магазин https://example.com

См. также -v, --verbose и -s, --silent. Добавлено в 7.67.0.
--no-идентификатор сеанса
(TLS) Отключить использование curl кэширования идентификатора сеанса SSL. По умолчанию все передачи выполняются с использованием кеша. Обратите внимание, что, хотя попытки повторного использования идентификаторов сеансов SSL никогда не повредят, похоже, что в дикой природе существуют сломанные реализации SSL, которые могут потребовать от вас отключить это, чтобы добиться успеха.
Обратите внимание, что это задокументированное инвертированное имя опции. Таким образом, вы можете использовать --sessionid для принудительного кэширования идентификатора сеанса.
Пример:
curl --no-sessionid https://example. com

См. также -k, --insecure.
--noproxy <список-не-прокси>
Список хостов, разделенных запятыми, для которых не следует использовать прокси, если он указан. Единственным подстановочным знаком является один символ *, который соответствует всем хостам и эффективно отключает прокси. Каждое имя в этом списке соответствует либо домену, содержащему имя хоста, либо самому имени хоста. Например, local.com будет соответствовать local.com, local.com:80 и www.local.com, но не www.notlocal.com.
Начиная с версии 7.53.0, этот параметр переопределяет переменные среды, отключающие прокси («no_proxy» и «NO_PROXY»). Если есть переменная среды, отключающая прокси-сервер, вы можете установить для списка noproxy значение «», чтобы переопределить его.
Пример:
curl --noproxy "www.example" https://example.com

См. также -x, --proxy.
--ntlm-wb
(HTTP) Включает NTLM в том же стиле, что и --ntlm, но передает аутентификацию отдельному двоичному приложению ntlmauth, которое выполняется при необходимости.
Пример:
curl --ntlm-wb -u пользователь:пароль https://example.com

См. также --ntlm и --proxy-ntlm.
--ntlm
(HTTP) Включает проверку подлинности NTLM. Метод аутентификации NTLM был разработан Microsoft и используется веб-серверами IIS. Это проприетарный протокол, переработанный умными людьми и реализованный в curl на основе их усилий. Такое поведение не следует одобрять, вы должны поощрять всех, кто использует NTLM, вместо этого перейти на общедоступный и документированный метод проверки подлинности, такой как дайджест.
Если вы хотите включить NTLM для проверки подлинности вашего прокси, используйте --proxy-ntlm.
Если эта опция используется несколько раз, используется только первая.
Пример:
curl --ntlm -u пользователь:пароль https://example.com

См. также --proxy-ntlm. --ntlm требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Эта опция взаимоисключающая для --basic и --negotiate и --digest и --anyauth.
--oauth3-bearer <токен>
(IMAP LDAP POP3 SMTP HTTP) Укажите токен носителя для аутентификации сервера OAUTH 2.0. Токен носителя используется в сочетании с именем пользователя, которое можно указать как часть параметров --url или --user.
Маркер носителя и имя пользователя отформатированы в соответствии с RFC 6750.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --oauth3-bearer "mF_9.B5f-4.1JqM" https://example.com

См. также --basic, --ntlm и --digest. Добавлено в 7.33.0.
--output-dir <каталог>
Эта опция указывает каталог, в котором должны храниться файлы, когда используются --remote-name или --output.
Указанный выходной каталог используется для всех URL-адресов и параметров вывода в командной строке, вплоть до первого -:, --next.
Если указанный целевой каталог не существует, операция завершится ошибкой, если также не используется --create-dirs.
Если этот параметр используется несколько раз, будет использован последний указанный каталог.
Пример:
curl --output-dir "tmp" -O https://example.com

См. также -O, --remote-name и -J, --remote-header-name. Добавлено в 7.73.0.
-o, --output <файл>
Запись вывода в вместо stdout. Если вы используете {} или [] для получения нескольких документов, вы должны указать URL-адрес в кавычках и можете использовать '#', за которым следует число в спецификаторе . Эта переменная будет заменена текущей строкой для извлекаемого URL-адреса. Как в:
curl "http://{one,two}.example.com" -o "file_#1.txt"

или используйте несколько переменных, например:
curl "http://{сайт,хост}.host[1-5].com" -o "#1_#2"

Вы можете использовать эту опцию столько раз, сколько у вас есть URL-адресов. Например, если вы укажете два URL-адреса в одной командной строке, вы можете использовать это следующим образом:
curl -o aa example. com -o bb example.net

и порядок параметров -o и URL-адресов не имеет значения, просто первый -o для первого URL-адреса и т. д., поэтому приведенную выше командную строку также можно записать как
curl example.com example.net -o aa -o bb

См. также параметр --create-dirs для динамического создания локальных каталогов. Указание вывода как «-» (одиночное тире) заставит вывод выполняться на стандартный вывод.
Чтобы подавить тела ответов, вы можете перенаправить вывод в /dev/null:
curl example.com -o /dev/null

Или для Windows используйте nul:
curl example.com -o ноль

Примеры:
curl -o файл https://example.com
curl "http://{one,two}.example.com" -o "file_#1.txt"
curl "http://{сайт,хост}.host[1-5].com" -o "#1_#2"
curl -o файл https://example.com -o файл2 https://example.net

См. также -O, --remote-name, --remote-name-all и -J, --remote-header-name.
--параллельно-немедленно
При выполнении параллельных передач эта опция указывает curl, что он должен предпочесть открывать больше параллельных соединений одновременно, а не ждать, чтобы увидеть, можно ли добавить новые передачи как мультиплексированные потоки в другом соединении.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl --parallel-immediate -Z https://example.com -o файл1 https://example.com -o файл2

См. также -Z, --parallel и --parallel-макс. Добавлено в 7.68.0.
--parallel-max <номер>
При запросе на параллельные передачи с использованием -Z, --parallel этот параметр определяет максимальное количество одновременных передач.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
По умолчанию 50.
Пример:
curl --parallel-max 100 -Z https://example.com ftp://example.com/

См. также -Z, --parallel. Добавлено в 7.66.0.
-Z, --параллельно
Заставляет curl выполнять свои передачи параллельно по сравнению с обычным последовательным способом.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl --parallel https://example.com -o файл1 https://example.com -o файл2

См. также -:, --next и -v, --verbose. Добавлено в 7.66.0.
--pass <фраза>
(SSH TLS) Парольная фраза для закрытого ключа.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --pass secret --key файл https://example.com

См. также --key и -u, --user.
--путь как есть
Указать curl не обрабатывать последовательности /../ или /./ в указанном пути URL. Обычно curl будет сжимать или объединять их в соответствии со стандартами, но с этим параметром вы говорите ему не делать этого.
Пример:
curl --path-as-is https://example.com/../../etc/passwd

См. также --request-target. Добавлено в 7.42.0.
--pinnedpubkey <хэши>
(TLS) Указывает curl использовать указанный файл открытого ключа (или хэши) для проверки узла. Это может быть путь к файлу, который содержит один открытый ключ в формате PEM или DER, или любое количество хэшей sha256 в кодировке base64, которым предшествует 'sha256//' и которые разделены ';'.
При согласовании соединения TLS или SSL сервер отправляет сертификат, указывающий его подлинность. Открытый ключ извлекается из этого сертификата, и если он не полностью соответствует открытому ключу, указанному в этой опции, curl прервет соединение перед отправкой или получением каких-либо данных.
Поддержка PEM/DER:
7.39.0: OpenSSL, GnuTLS и GSKit
7.43.0: NSS и wolfSSL
7.47.0: mbedtls
поддержка ша256:
7.44.0: OpenSSL, GnuTLS, NSS и wolfSSL
7.47.0: mbedtls
Другие серверные части SSL не поддерживаются.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --pinnedpubkey ключевой файл https://example.com
curl --pinnedpubkey 'sha256//ce118b51897f4452dc https://example.com

См. также --hostpubsha256. Добавлено в 7.39.0.
--post301
(HTTP) Указывает curl соблюдать RFC 7231/6.4.2 и не преобразовывать запросы POST в запросы GET при выполнении перенаправления 301. Поведение, отличное от RFC, широко распространено в веб-браузерах, поэтому curl выполняет преобразование по умолчанию для обеспечения согласованности. Однако сервер может потребовать, чтобы POST оставался POST после такого перенаправления. Эта опция имеет смысл только при использовании -L, --location.
Пример:
curl --post301 --location -d "данные" https://example.com

См. также --post302, --post303 и -L, --location.
--post302
(HTTP) Указывает curl соблюдать RFC 7231/6.4.3 и не преобразовывать запросы POST в запросы GET при выполнении перенаправления 302. Поведение, отличное от RFC, широко распространено в веб-браузерах, поэтому curl выполняет преобразование по умолчанию для обеспечения согласованности. Однако сервер может потребовать, чтобы POST оставался POST после такого перенаправления. Эта опция имеет смысл только при использовании -L, --location.
Пример:
curl --post302 --location -d "данные" https://example.com

См. также --post301, --post303 и -L, --location.
--post303
(HTTP) Указывает curl нарушать RFC 7231/6.4.4 и не преобразовывать запросы POST в запросы GET при выполнении перенаправления 303. Сервер может потребовать, чтобы POST оставался POST после перенаправления 303. Эта опция имеет смысл только при использовании -L, --location.
Пример:
curl --post303 --location -d "данные" https://example.com

См. также --post302, --post301 и -L, --location.
--preproxy [протокол://]хост[:порт]
Использовать указанный прокси-сервер SOCKS перед подключением к HTTP или HTTPS -x, --proxy. В таком случае curl сначала подключается к прокси-серверу SOCKS, а затем подключается (через SOCKS) к прокси-серверу HTTP или HTTPS. Следовательно, пре-прокси.
Строка пре-прокси должна быть указана с префиксом protocol://, чтобы указать альтернативные протоколы прокси. Используйте socks4://, socks4a://, socks5:// или socks5h://, чтобы запросить использование конкретной версии SOCKS. Никакой указанный протокол не сделает curl по умолчанию SOCKS4.
Если номер порта не указан в строке прокси, предполагается, что он равен 1080.
Пользователь и пароль, которые могут быть указаны в строке прокси-сервера, декодируются URL-адресом curl. Это позволяет передавать специальные символы, такие как @, с помощью %40 или двоеточие с %3a.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --preproxy socks5://proxy.example -x http://http.example https://example.com

См. также -x, --proxy и --socks5. Добавлено в 7.52.0.
-#, --прогресс-бар
Заставить curl отображать прогресс передачи в виде простого индикатора выполнения вместо стандартного, более информативного индикатора.
Этот индикатор выполнения рисует на экране одну строку из символов «#» и показывает процентное значение, если известен размер передачи. Для передачи без известного размера будет космический корабль (-=o=-), который перемещается взад и вперед, но только во время передачи данных, с набором летающих символов решетка наверху.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl -# -O https://example.com

См. также --styled-output.
--proto-default <протокол>
Сообщает curl использовать протокол для любого URL-адреса, в котором отсутствует имя схемы.
Неизвестный или неподдерживаемый протокол вызывает ошибку CURLE_UNSUPPORTED_PROTOCOL (1).
Этот параметр не изменяет протокол прокси-сервера по умолчанию (http).
Если этот параметр не установлен, curl выбирает протокол на основе имени хоста, подробности см. в разделе --url.
Пример:
curl --proto-default https ftp.example.com

См. также --proto и --proto-redir. Добавлено в 7.45.0.
--proto-redir <протоколы>
Указывает curl ограничить количество протоколов, которые он может использовать при перенаправлении. Протоколы, запрещенные параметром --proto, не переопределяются этой опцией. См. --proto для того, как представлены протоколы.
Пример, разрешить только HTTP и HTTPS при перенаправлении:
curl --proto-redir -all,http,https http://example.com

По умолчанию curl разрешает только HTTP, HTTPS, FTP и FTPS при перенаправлении (начиная с версии 7.65.2). Указание all или +all включает все протоколы при перенаправлении, что не очень хорошо для безопасности.
Пример:
curl --proto-redir =http,https https://example.com

См. также --proto.
--proto <протоколы>
Приказывает curl ограничить количество протоколов, которые он может использовать для передачи. Протоколы оцениваются слева направо, разделяются запятыми, и каждый из них представляет собой имя протокола или «все», с необязательным префиксом из нуля или более модификаторов. Доступные модификаторы:
+ Разрешить этот протокол в дополнение к уже разрешенным протоколам (это значение по умолчанию, если модификатор не используется).
- Запретить этот протокол, удалив его из списка уже разрешенных протоколов.
= Разрешить только этот протокол (игнорируя уже разрешенный список), хотя позже он может быть изменен последующими записями в списке, разделенном запятыми.
Например:
--proto -ftps использует протоколы по умолчанию, но отключает ftps
--proto -all,https,+http включает только http и https
--proto =http,https также включает только http и https
Неизвестные и отключенные протоколы выдают предупреждение. Это позволяет сценариям безопасно полагаться на возможность отключения потенциально опасных протоколов, не полагаясь на поддержку этого протокола, встроенную в curl, чтобы избежать ошибки.
Этот параметр можно использовать несколько раз, и в этом случае эффект будет таким же, как при объединении протоколов в один экземпляр параметра.
Пример:
curl --proto =http,https,sftp https://example.com

См. также --proto-redir и --proto-default.
--proxy-anyauth
Сообщает curl выбрать подходящий метод аутентификации при обмене данными с данным HTTP-прокси. Это может вызвать дополнительный запрос/ответ туда и обратно.
Пример:
curl --proxy-anyauth --proxy-user user:passwd -x proxy https://example.com

См. также -x, --proxy, --proxy-basic и --proxy-digest.
--прокси-базовый
Указывает curl использовать обычную HTTP-аутентификацию при обмене данными с данным прокси-сервером. Используйте --basic для включения HTTP Basic с удаленным хостом. Базовый — это метод аутентификации по умолчанию, который curl использует с прокси.
Пример:
curl --proxy-basic --proxy-user user:passwd -x proxy https://example.com

См. также -x, --proxy, --proxy-anyauth и --proxy-digest.
--proxy-cacert <файл>
То же, что --cacert, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-cacert CA-file.txt -x https://proxy https://example.com

См. также --proxy-capath, --cacert, --capath и -x, --proxy. Добавлено в 7.52.0.
--proxy-capath <каталог>
То же, что и --capath, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-capath /local/directory -x https://proxy https://example.com

См. также --proxy-cacert, -x, --proxy и --capath. Добавлено в 7.52.0.
--прокси-сертификат <тип>
То же, что и --cert-type, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-cert-type PEM --proxy-cert file -x https://proxy https://example.com

См. также --proxy-cert. Добавлено в 7.52.0.
--proxy-cert
То же, что --cert, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-cert file -x https://proxy https://example.com

См. также --proxy-cert-type. Добавлено в 7.52.0.
--прокси-шифры <список>
То же, что и --ciphers, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-ciphers ECDHE-ECDSA-AES256-CCM8 -x https://proxy https://example.com

См. также --ciphers, --curves и -x, --proxy. Добавлено в 7.52.0.
--proxy-crlfile <файл>
То же, что --crlfile, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-crlfile rejects.txt -x https://proxy https://example.com

См. также --crlfile и -x, --proxy. Добавлено в 7.52.0.
--прокси-дайджест
Указывает curl использовать аутентификацию HTTP Digest при обмене данными с данным прокси-сервером. Используйте --digest для включения дайджеста HTTP с удаленным хостом.
Пример:
curl --proxy-digest --proxy-user user:passwd -x proxy https://example.com

См. также -x, --proxy, --proxy-anyauth и --proxy-basic.
--proxy-header <заголовок/@файл>
(HTTP) Дополнительный заголовок для включения в запрос при отправке HTTP на прокси. Вы можете указать любое количество дополнительных заголовков. Это параметр, эквивалентный --header, но предназначенный только для связи с прокси-сервером, как в запросах CONNECT, когда вы хотите, чтобы прокси-сервер отправлял отдельный заголовок для того, что отправляется на фактический удаленный хост.
curl позаботится о том, чтобы каждый заголовок, который вы добавляете/заменяете, был отправлен с правильным маркером конца строки, поэтому вам не следует добавлять его как часть содержимого заголовка: не добавляйте новые строки или возврат каретки, они будут только портить вещи для вас.
Заголовки, указанные с помощью этой опции, не будут включены в запросы, которые, как знает curl, не будут отправлены на прокси-сервер.
Начиная с версии 7.55.0, эта опция может принимать аргумент в стиле @filename, который затем добавляет заголовок для каждой строки во входном файле. Использование @- заставит curl прочитать заголовочный файл со стандартного ввода.
Эту опцию можно использовать несколько раз для добавления/замены/удаления нескольких заголовков.
Примеры:
curl --proxy-header "X-First-Name: Joe" -x http://proxy https://example.com
curl --proxy-header "User-Agent: сюрприз" -x http://proxy https://example.com
curl --proxy-header "Хост:" -x http://proxy https://example. com

См. также -x, --proxy. Добавлено в 7.37.0.
--прокси-небезопасный
То же, что --insecure, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-insecure -x https://proxy https://example.com

См. также -x, --proxy и -k, --insecure. Добавлено в 7.52.0.
--proxy-key-type <тип>
То же, что --key-type, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-key-type DER --proxy-key здесь -x https://proxy https://example.com

См. также --proxy-key и -x, --proxy. Добавлено в 7.52.0.
--proxy-key <ключ>
То же, что --key, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-key здесь -x https://proxy https://example.com

См. также --proxy-key-type и -x, --proxy. Добавлено в 7.52.0.
--прокси-согласование
Сообщает curl использовать аутентификацию HTTP Negotiate (SPNEGO) при обмене данными с данным прокси. Используйте --negotiate для включения согласования HTTP (SPNEGO) с удаленным хостом.
Пример:
curl --proxy-negotiate --proxy-user user:passwd -x proxy https://example.com

См. также --proxy-anyauth и --proxy-basic.
--proxy-ntlm
Указывает curl использовать аутентификацию HTTP NTLM при обмене данными с данным прокси-сервером. Используйте --ntlm для включения NTLM с удаленным хостом.
Пример:
curl --proxy-ntlm --proxy-user user:passwd -x http://proxy https://example.com

См. также --proxy-negotiate и --proxy-anyauth.
--proxy-pass <фраза>
То же, что и --pass, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-pass secret --proxy-key здесь -x https://proxy https://example.com

См. также -x, --proxy и --proxy-key. Добавлено в 7.52.0.
--proxy-pinnedpubkey <хэши>
(TLS) Указывает curl использовать указанный файл открытого ключа (или хэши) для проверки прокси-сервера. Это может быть путь к файлу, который содержит один открытый ключ в формате PEM или DER, или любое количество хэшей sha256 в кодировке base64, которым предшествует 'sha256//' и которые разделены ';'.
При согласовании соединения TLS или SSL сервер отправляет сертификат, указывающий его подлинность. Открытый ключ извлекается из этого сертификата, и если он не полностью соответствует открытому ключу, указанному в этой опции, curl прервет соединение перед отправкой или получением каких-либо данных.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --proxy-pinnedpubkey ключевой файл https://example.com
curl --proxy-pinnedpubkey 'sha256//ce118b51897f4452dc https://example.com

См. также --pinnedpubkey и -x, --proxy. Добавлено в 7.59.0.
--имя-прокси-службы <имя>
Этот параметр позволяет изменить имя службы для согласования прокси.
Пример:
curl --proxy-service-name "кустарник" -x прокси https://example. com

См. также --service-name и -x, --proxy. Добавлено в 7.43.0.
--proxy-ssl-разрешить зверь
То же, что и --ssl-allow-beast, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-ssl-allow-beast -x https://proxy https://example.com

См. также --ssl-allow-beast и -x, --proxy. Добавлено в 7.52.0.
--proxy-ssl-auto-client-cert
То же, что и --ssl-auto-client-cert, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-ssl-auto-client-cert -x https://proxy https://example.com

См. также --ssl-auto-client-cert и -x, --proxy. Добавлено в 7.77.0.
--proxy-tls13-ciphers <список наборов шифров>
(TLS) Указывает, какие наборы шифров следует использовать при подключении к прокси-серверу HTTPS при согласовании TLS 1.3. В списке наборов шифров должны быть указаны допустимые шифры. Ознакомьтесь с информацией о наборе шифров TLS 1.3 по этому URL-адресу:
https://curl. se/docs/ssl-ciphers.html

Этот параметр в настоящее время используется только в том случае, если curl создан для использования OpenSSL 1.1.1 или более поздней версии. Если вы используете другую серверную часть SSL, вы можете попробовать установить наборы шифров TLS 1.3, используя параметр --proxy-ciphers.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --proxy-tls13-ciphers TLS_AES_128_GCM_SHA256 -x прокси https://example.com

См. также --tls13-ciphers и --curves. Добавлено в 7.61.0.
--proxy-tlsauthtype <тип>
То же, что --tlsauthtype, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-tlsauthtype SRP -x https://proxy https://example.com

См. также -x, --proxy и --proxy-tlsuser. Добавлено в 7.52.0.
--proxy-tlspassword <строка>
То же, что и --tlspassword, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-tlspassword пароль -x https://proxy https://example. com

См. также -x, --proxy и --proxy-tlsuser. Добавлено в 7.52.0.
--proxy-tlsuser <имя>
То же, что и --tlsuser, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-tlsuser smith -x https://proxy https://example.com

См. также -x, --proxy и --proxy-tlspassword. Добавлено в 7.52.0.
--прокси-tlsv1
То же, что --tlsv1, но используется в контексте HTTPS-прокси.
Пример:
curl --proxy-tlsv1 -x https://proxy https://example.com

См. также -x, --proxy. Добавлено в 7.52.0.
-U, --proxy-user <пользователь:пароль>
Укажите имя пользователя и пароль для аутентификации прокси-сервера.
Если вы используете двоичный файл curl с поддержкой Windows SSPI и выполняете аутентификацию Negotiate или NTLM, вы можете указать curl выбрать имя пользователя и пароль из вашей среды, указав одно двоеточие с этой опцией: «-U :».
В системах, где это работает, curl будет скрывать данный аргумент опции из листингов процессов. Этого недостаточно для защиты учетных данных от возможного просмотра другими пользователями в той же системе, поскольку они все еще будут видны некоторое время, прежде чем будут очищены. Такие конфиденциальные данные следует извлекать из файла или аналогичного файла и никогда не использовать в виде открытого текста в командной строке.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --proxy-имя пользователя:pwd -x прокси https://example.com

См. также --proxy-pass.
-x, --proxy [протокол://]хост[:порт]
Использовать указанный прокси.
Строка прокси может быть указана с префиксом protocol://. Протокол не указан, или http:// будет рассматриваться как HTTP-прокси. Используйте socks4://, socks4a://, socks5:// или socks5h://, чтобы запросить использование конкретной версии SOCKS.
Сокеты домена Unix поддерживаются для socks-прокси. Установите localhost для хост-части. например socks5h://локальный/путь/к/socket. sock
Поддержка прокси-сервера HTTPS через префикс протокола https:// была добавлена в 7.52.0 для OpenSSL, GnuTLS и NSS.
Нераспознанные и неподдерживаемые прокси-протоколы вызывают ошибку, начиная с версии 7.52.0. Предыдущие версии могут игнорировать протокол и использовать вместо него http://.
Если номер порта не указан в строке прокси, предполагается, что он равен 1080.
Этот параметр переопределяет существующие переменные среды, которые задают использование прокси-сервера. Если есть переменная среды, задающая прокси, вы можете установить прокси на «», чтобы переопределить его.
Все операции, выполняемые через HTTP-прокси, будут прозрачно преобразованы в HTTP. Это означает, что некоторые специфичные для протокола операции могут быть недоступны. Это не тот случай, если вы можете туннелировать через прокси, например, с опцией --proxytunnel.
Пользователь и пароль, которые могут быть указаны в строке прокси-сервера, декодируются URL-адресом curl. Это позволяет передавать специальные символы, такие как @, с помощью %40 или двоеточие с %3a.
Прокси-хост можно указать так же, как и переменные среды прокси, включая префикс протокола (http://) и встроенный пользователь + пароль.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --proxy http://proxy.example https://example.com

См. также --socks5 и --proxy-basic.
--proxy1.0 <хост[:порт]>
Использовать указанный прокси-сервер HTTP 1.0. Если номер порта не указан, предполагается, что это порт 1080.
Единственная разница между этим параметром и параметром прокси-сервера HTTP -x, --proxy заключается в том, что попытки использовать CONNECT через прокси-сервер будут указывать протокол HTTP 1.0 вместо HTTP 1.1 по умолчанию.
Пример:
curl --proxy1.0 -x http://proxy https://example.com

См. также -x, --proxy, --socks5 и --preproxy.
-p, --proxytunnel
Когда используется прокси-сервер HTTP -x, --proxy, эта опция создаст туннель curl через прокси-сервер. Туннельный подход реализуется с помощью HTTP-запроса CONNECT прокси-сервера и требует, чтобы прокси-сервер разрешал прямое подключение к номеру удаленного порта, через который curl хочет выполнить туннелирование.
Чтобы подавить заголовки ответа прокси-сервера CONNECT, когда curl настроен на выходные заголовки, используйте --suppress-connect-headers.
Пример:
curl --proxytunnel -x http://proxy https://example.com

См. также -x, --proxy.
--pubkey <ключ>
(SFTP SCP) Имя файла открытого ключа. Позволяет вам указать ваш открытый ключ в этом отдельном файле.
Если эта опция используется несколько раз, будет использована последняя.
(Начиная с версии 7.39.0, curl пытается автоматически извлечь открытый ключ из файла закрытого ключа, поэтому передача этой опции обычно не требуется. Обратите внимание, что для этого извлечения открытого ключа требуется, чтобы libcurl был связан с копией libssh3 1.2. 8 или выше, который сам связан с OpenSSL. )
Пример:
curl --pubkey файл.pub sftp://example.com/

См. также --pass.
-Q, --quote <команда>
(FTP SFTP) Отправка произвольной команды на удаленный сервер FTP или SFTP. Команды кавычек отправляются ДО того, как произойдет передача (точнее, сразу после начальной команды PWD при передаче по FTP). Чтобы команды выполнялись после успешной передачи, поставьте перед ними дефис «-».
(только FTP) Чтобы команды отправлялись после того, как curl изменил рабочий каталог, непосредственно перед командой (командами) передачи файлов добавьте к команде префикс «+». Это не выполняется, когда выполняется листинг каталога.
Вы можете указать любое количество команд.
По умолчанию curl останавливается при первом сбое. Чтобы curl продолжал работать даже в случае сбоя команды, поставьте перед командой звездочку (*). В противном случае, если сервер вернет ошибку для одной из команд, вся операция будет прервана.
Вы должны отправлять FTP-серверам синтаксически правильные команды, как определено в RFC 959, или одну из команд, перечисленных ниже, на SFTP-серверы.
Эту опцию можно использовать несколько раз.
SFTP — это двоичный протокол. В отличие от FTP, curl сам интерпретирует команды кавычек SFTP, прежде чем отправлять их на сервер. Имена файлов могут быть заключены в кавычки в стиле оболочки для включения пробелов или специальных символов. Ниже приведен список всех поддерживаемых команд кавычек SFTP:
atime файл даты
Команда atime устанавливает время последнего доступа к файлу, указанному в файловом операнде. <выражение даты> может быть строкой даты всех видов, см. справочную страницу curl_getdate(3) для деталей выражения даты. (Добавлено в 7.73.0)
групповой файл chgrp
Команда chgrp устанавливает идентификатор группы файла, имя которого указано в файловом операнде, равным идентификатору группы, указанному в групповом операнде. Групповой операнд представляет собой идентификатор группы в виде десятичного целого числа.
файл режима chmod
Команда chmod изменяет биты режима файла указанного файла. Операнд режима представляет собой восьмеричное целое число режима.
файл пользователя chown
Команда chown устанавливает владельцем файла, указанного в файловом операнде, идентификатор пользователя, указанный в пользовательском операнде. Пользовательский операнд представляет собой идентификатор пользователя в виде десятичного целого числа.
ln исходный_файл целевой_файл
Команды ln и symlink создают символическую ссылку в расположении target_file, указывающую на расположение исходного_файла.
mkdir имя_каталога
Команда mkdir создает каталог, названный операндом directory_name.
mtime файл даты
Команда mtime устанавливает время последней модификации файла, указанного в файловом операнде. <выражение даты> может быть строкой даты всех видов, см. справочную страницу curl_getdate(3) для деталей выражения даты. (Добавлено в 7.73.0)
пароль
Команда pwd возвращает абсолютный путь к текущему рабочему каталогу.
переименовать исходную цель
Команда rename переименовывает файл или каталог, указанный в исходном операнде, в путь назначения, указанный в целевом операнде.
РМ-файл
Команда rm удаляет файл, указанный файловым операндом.
каталог rmdir
Команда rmdir удаляет запись каталога, указанную операндом каталога, если она пуста.
символическая ссылка исходный_файл целевой_файл
См. пер.
Пример:
curl --quote "Файл DELE" ftp://example.com/foo

См. также -X, --request.
--random-file <файл>
Устаревшая опция. Эта опция игнорируется curl, начиная с версии 7.84.0. До этого он влиял на curl только в том случае, если он был создан для использования старых версий OpenSSL.
Укажите путь к файлу, содержащему то, что будет считаться случайными данными. Эти данные могут использоваться для заполнения механизма случайных чисел SSL-соединениями.
Пример:
curl --random-file мусор https://example. com

См. также --egd-file.
-r, --range <диапазон>
(HTTP FTP SFTP FILE) Получить диапазон байтов (т. е. часть документа) с сервера HTTP/1.1, FTP или SFTP или из локального ФАЙЛА. Диапазоны могут быть указаны несколькими способами.
0-499 определяет первые 500 байт
500-999 указывает вторые 500 байт
-500 указывает последние 500 байт
9500- указывает байты со смещения 9500 и далее
0-0,-1 указывает только первый и последний байт (*) (HTTP)
100-199,500-599 задает два отдельных 100-байтовых диапазона(*) (HTTP)
(*) = ОБРАТИТЕ ВНИМАНИЕ, что это заставит сервер ответить составным ответом, который будет возвращен curl как есть! За синтаксический анализ или иное преобразование этого ответа отвечает вызывающая сторона.
В полях «начало» и «стоп» синтаксиса диапазона «начало-стоп» допустимы только цифровые символы (0-9). Если в диапазоне указан нецифровой символ, ответ сервера будет неопределенным, в зависимости от конфигурации сервера.
Вы также должны знать, что на многих серверах HTTP/1.1 эта функция не включена, поэтому при попытке получить диапазон вместо этого вы получите весь документ.
Загрузки диапазона FTP и SFTP поддерживают только простой синтаксис «старт-стоп» (опционально с одним из опущенных номеров). Использование FTP зависит от расширенной команды FTP SIZE.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --range 22-44 https://example.com

См. также -C, --continue-at и -a, --append.
--rate <максимальная частота запросов>
Укажите максимальную частоту передачи, которую вы разрешаете использовать curl, в количестве запусков передачи в единицу времени (иногда называемую скоростью запроса). Без этой опции curl начнет следующую передачу как можно быстрее.
Если задано несколько URL-адресов и передача выполняется быстрее разрешенной скорости, curl будет ждать, пока не начнется следующая передача, чтобы поддерживать запрошенную скорость. Эта опция не действует при использовании --parallel.
Частота запросов представлена как «N/U», где N — целое число, а U — единица времени. Поддерживаемые единицы измерения: «с» (секунда), «м» (минута), «ч» (час) и «д» / (день, как в 24-часовой системе). Единицей времени по умолчанию, если не указано «/U», является количество передач в час.
Если curl разрешить 10 запросов в минуту, он не начнет следующий запрос, пока не пройдет 6 секунд с момента начала предыдущей передачи.
Эта функция использует миллисекундное разрешение. Если разрешенная частота установлена более 1000 в секунду, вместо этого она будет работать без ограничений.
При повторных попытках передачи, включенных параметром --retry, используется отдельная логика задержки повтора, а не этот параметр.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --rate 2/с https://example.com
curl --rate 3/ч https://example.com
curl --rate 14/м https://example. com

См. также --limit-rate и --retry-delay. Добавлено в 7.84.0.
--необработанный
(HTTP) При использовании он отключает все внутреннее HTTP-декодирование содержимого или кодирование передачи и вместо этого передает их без изменений, в необработанном виде.
Пример:
curl --raw https://example.com

См. также --tr-encoding.
-e, --referer
(HTTP) Отправляет информацию «Страница реферера» на HTTP-сервер. Конечно, это также можно установить с помощью флага --header. При использовании с --location вы можете добавить «;auto» к URL-адресу --referer, чтобы curl автоматически устанавливал предыдущий URL-адрес, когда он следует за заголовком Location:. Строку ";auto" можно использовать отдельно, даже если вы не установили начальные -e, --referer.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl --referer "https://fake.example" https://example.com
curl --referer "https://fake. example;auto" -L https://example.com
curl --referer ";auto" -L https://example.com

См. также -A, --user-agent и -H, --header.
-J, --remote-header-name
(HTTP) Этот параметр указывает параметру --remote-name использовать указанное сервером имя файла Content-Disposition вместо извлечения имени файла из URL-адреса. Если предоставленное сервером имя файла содержит путь, он будет удален перед использованием имени файла.
Файл сохраняется в текущем каталоге или в каталоге, указанном параметром --output-dir.
Если сервер указывает имя файла, а файл с таким именем уже существует в целевом каталоге, он не будет перезаписан и произойдет ошибка. Если сервер не указывает имя файла, эта опция не действует.
Попытки декодировать %-последовательности (пока) в указанном имени файла не предпринимались, поэтому эта опция может предоставить вам довольно неожиданные имена файлов.
ПРЕДУПРЕЖДЕНИЕ. Используйте этот параметр с осторожностью, особенно в Windows. Мошеннический сервер может отправить вам имя DLL или другого файла, который может быть автоматически загружен Windows или каким-либо сторонним программным обеспечением.
Пример:
завиток -OJ https://example.com/file

См. также -O, --remote-name.
--remote-name-all
Этот параметр изменяет действие по умолчанию для всех заданных URL-адресов, как если бы для каждого из них использовалось --remote-name. Поэтому, если вы хотите отключить это для определенного URL-адреса после использования --remote-name-all, вы должны использовать "-o -" или --no-remote-name.
Пример:
curl --remote-name-all ftp://example.com/file1 ftp://example.com/file2

См. также -O, --remote-name.
-O, --remote-имя
Запись вывода в локальный файл с именем, подобным удаленному файлу, который мы получили. (Используется только файловая часть удаленного файла, путь обрезается.)
Файл будет сохранен в текущем рабочем каталоге. Если вы хотите, чтобы файл был сохранен в другом каталоге, убедитесь, что вы изменили текущий рабочий каталог перед вызовом curl с этой опцией или используйте --output-dir.
Имя удаленного файла, используемого для сохранения, извлекается из заданного URL-адреса и ничего больше, и если оно уже существует, оно будет перезаписано. Если вы хотите, чтобы сервер мог выбрать имя файла, обратитесь к параметру --remote-header-name, который можно использовать в дополнение к этой опции. Если сервер выбирает имя файла, и это имя уже существует, оно не будет перезаписано.
Для имени файла не выполняется декодирование URL-адреса. Если у него есть %20 или другие части имени, закодированные в URL, они будут в конечном итоге как имя файла.
Вы можете использовать эту опцию столько раз, сколько у вас есть URL-адресов.
Пример:
завиток -O https://example.com/имя_файла

См. также --remote-name-all, --output-dir и -J, --remote-header-name.
-R, --remote-время
При использовании это заставит curl попытаться определить временную метку удаленного файла и, если она доступна, сделать так, чтобы локальный файл получил ту же самую временную метку.
Пример:
curl --remote-time -o foo https://example.com

См. также -O, --remote-name и -z, --time-cond.
--удалить-при-ошибке
Когда curl возвращает ошибку при попытке сохранить вывод в локальном файле, этот параметр удаляет этот сохраненный файл перед выходом. Это препятствует тому, чтобы curl оставил частичный файл в случае ошибки во время передачи.
Если вывод не является файлом, этот параметр не действует.
Пример:
curl --remove-on-error -o вывод https://example.com

См. также -f, --fail. Добавлено в 7.83.0.
--request-цель <путь>
(HTTP) Сообщает curl использовать альтернативную «цель» (путь) вместо использования пути, указанного в URL-адресе. Особенно полезно, когда вы хотите отправлять HTTP-запросы без косой черты или других данных, которые не соответствуют обычному шаблону URL, например «OPTIONS *».
Пример:
curl --request-target "*" -X ВАРИАНТЫ https://example. com

См. также -X, --request. Добавлено в 7.55.0.
-X, --request <метод>
(HTTP) Указывает пользовательский метод запроса, используемый при обмене данными с HTTP-сервером. Указанный метод запроса будет использоваться вместо метода, используемого в противном случае (по умолчанию это GET). Прочтите спецификацию HTTP 1.1 для получения подробной информации и пояснений. Общие дополнительные HTTP-запросы включают PUT и DELETE, но связанные технологии, такие как WebDAV, предлагают PROPFIND, COPY, MOVE и многое другое.
Обычно эта опция не требуется. Все виды запросов GET, HEAD, POST и PUT скорее вызываются с помощью специальных параметров командной строки.
Этот параметр изменяет только фактическое слово, используемое в HTTP-запросе, но не влияет на поведение curl. Так, например, если вы хотите сделать правильный запрос HEAD, использования -X HEAD будет недостаточно. Вам нужно использовать опцию --head.
Строка метода, которую вы установили с помощью --request, будет использоваться для всех запросов, которые, если вы, например, используете --location, могут вызвать непреднамеренные побочные эффекты, когда curl не изменяет метод запроса в соответствии с кодами ответа HTTP 30x - и тому подобное .
(FTP) Указывает пользовательскую команду FTP для использования вместо LIST при создании списков файлов с помощью FTP.
(POP3) Указывает пользовательскую команду POP3 для использования вместо LIST или RETR.
(IMAP) Указывает пользовательскую команду IMAP для использования вместо LIST. (Добавлено в 7.30.0)
(SMTP) Указывает пользовательскую команду SMTP для использования вместо HELP или VRFY. (Добавлено в 7.34.0)
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl -X "УДАЛИТЬ" https://example.com
curl -X NLST ftp://example.com/

См. также --request-target.
--resolve <[+]хост:порт:адрес[адрес]...>
Укажите пользовательский адрес для определенной пары хост-порт. Используя это, вы можете заставить запросы curl использовать указанный адрес и предотвратить использование обычно разрешенного адреса. Считайте это своего рода альтернативой /etc/hosts, представленной в командной строке. Номер порта должен быть номером, используемым для конкретного протокола, для которого будет использоваться хост. Это означает, что вам нужно несколько записей, если вы хотите указать адрес для одного и того же хоста, но разных портов.
Указав «*» в качестве хоста, вы можете указать curl разрешить любой хост и конкретную пару портов по указанному адресу. Подстановочный знак разрешается последним, поэтому любой --resolve с определенным хостом и портом будет использоваться первым.
Предоставленный адрес, установленный этой опцией, будет использоваться, даже если --ipv4 или --ipv6 установлены, чтобы заставить curl использовать другую версию IP.
Поставив перед хостом префикс «+», вы можете сделать время записи истекшим после тайм-аута curl по умолчанию (1 минута). Обратите внимание, что это имеет смысл только для длительных параллельных передач с большим количеством файлов. В таких случаях, если используется этот параметр, curl попытается разрешить хост, как обычно, после истечения времени ожидания.
В версии 7.57.0 добавлена поддержка указания IP-адреса в [скобках].
Поддержка предоставления нескольких IP-адресов для каждой записи была добавлена в 7.59.0.
Поддержка разрешения с использованием подстановочных знаков была добавлена в 7.64.0.
Поддержка префикса «+» была добавлена в 7.75.0.
Эту опцию можно использовать много раз, чтобы добавить множество имен хостов для разрешения.
Пример:
curl --resolve example.com:443:127.0.0.1 https://example.com

См. также --connect-to и --alt-svc.
--повторить все ошибки
Повторите попытку при любой ошибке. Эта опция используется вместе с --retry.
Этот вариант является "кувалдой" повторной попытки. Не используйте эту опцию по умолчанию (например, в curlrc), это может привести к непредвиденным последствиям, таким как отправка или получение повторяющихся данных. Не используйте с перенаправленным вводом или выводом. Вам было бы намного лучше решать свои уникальные проблемы в сценарии оболочки. Пожалуйста, прочтите приведенный ниже пример.
ПРЕДУПРЕЖДЕНИЕ. Для совместимости с сервером curl пытается повторить неудачную ненадежную передачу как можно ближе к тому, как она была запущена, но это невозможно с перенаправленным вводом или выводом. Например, перед повторной попыткой удаляются выходные данные неудачной частичной передачи, которые были записаны в выходной файл. Однако это не относится к данным, перенаправленным на | pipe или > файл, которые не сбрасываются. Мы настоятельно рекомендуем вам не анализировать и не записывать выходные данные с помощью перенаправления в сочетании с этой опцией, так как вы можете получить дублирующиеся данные.
По умолчанию curl не выдает ошибку в коде ответа HTTP, который указывает на ошибку HTTP, если передача прошла успешно. Например, если сервер отвечает 404 Not Found и ответ полностью получен, это не является ошибкой. Когда используется --retry, curl будет повторять некоторые коды ответов HTTP, которые указывают на временные ошибки HTTP, но не включает большинство кодов ответов 4xx, таких как 404. Если вы хотите повторить все коды ответов, которые указывают на ошибки HTTP (4xx и 5xx), затем объедините с -f, --fail.
Пример:
curl --retry 5 --retry-all-errors https://example.com

См. также --retry. Добавлено в 7.71.0.
--retry-connrefused
В дополнение к другим условиям ECONNREFUSED также следует рассматривать как временную ошибку для --retry. Эта опция используется вместе с --retry.
Пример:
curl --retry-connrefused --retry https://example.com

См. также --retry и --retry-all-errors. Добавлено в 7.52.0.
--retry-delay <секунды>
Сделать curl спящим на это время перед каждой повторной попыткой, когда передача завершилась неудачно из-за временной ошибки (это изменяет алгоритм времени отсрочки по умолчанию между повторными попытками). Эта опция интересна только в том случае, если используется --retry. Установка этой задержки на ноль заставит curl использовать время отсрочки по умолчанию.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --retry-delay 5 --retry https://example.com

См. также --retry.
--retry-max-time <секунды>
Таймер повтора сбрасывается перед первой попыткой передачи. Повторные попытки будут выполняться как обычно (см. --retry), пока таймер не достиг заданного предела. Обратите внимание, что если таймер не достиг предела, запрос будет выполнен, и его выполнение может занять больше времени, чем заданный период времени. Чтобы ограничить максимальное время одного запроса, используйте -m, --max-time. Установите этот параметр на ноль, чтобы не было повторных попыток тайм-аута.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --retry-max-time 30 --retry 10 https://example.com

См. также --retry.
--retry <номер>
Если при попытке curl выполнить передачу возвращается временная ошибка, он будет повторять это количество раз, прежде чем сдаться. Установка числа в 0 заставляет curl не делать повторных попыток (по умолчанию). Временная ошибка означает: тайм-аут, код ответа FTP 4xx или HTTP 408, 429., 500, 502, 503 или 504 код ответа.
Когда curl собирается повторить попытку передачи, он сначала подождет одну секунду, а затем для всех предстоящих попыток удвоит время ожидания, пока не достигнет 10 минут, что будет задержкой между остальными попытками. Используя --retry-delay, вы отключаете этот алгоритм экспоненциальной отсрочки. См. также параметр --retry-max-time, чтобы ограничить общее время повторных попыток.
Начиная с версии curl 7.66.0, curl будет соответствовать заголовку ответа Retry-After:, если он присутствует, чтобы знать, когда выполнить следующую повторную попытку.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --retry 7 https://example.com

См. также --retry-max-time.
--sasl-authzid <идентификатор>
Используйте этот идентификатор авторизации (authzid) во время аутентификации SASL PLAIN в дополнение к идентификатору аутентификации (authcid), указанному параметрами -u, --user.
Если параметр не указан, сервер будет получать authzid из authcid, но если он указан и в зависимости от реализации сервера, он может использоваться для доступа к почтовому ящику другого пользователя, к которому пользователю был предоставлен доступ, или общий почтовый ящик, например.
Пример:
curl --sasl-authzid zid imap://example.com/

См. также --login-options. Добавлено в 7.66.0.
--sasl-ир
Включить начальный ответ при аутентификации SASL.
Пример:
curl --sasl-ir imap://example.com/

См. также --sasl-authzid. Добавлено в 7.31.0.
--service-name <имя>
Этот параметр позволяет изменить имя службы для SPNEGO.
Примеры: --negotiate --service-name sockd будет использовать sockd/имя-сервера.
Пример:
curl --service-name sockd/сервер https://example.com

См. также --negotiate и --proxy-service-name. Добавлено в 7.43.0.
-S, --show-ошибка
При использовании с параметрами -s, --silent заставляет curl показывать сообщение об ошибке в случае сбоя.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl --show-error --silent https://example.com

См. также --no-progress-meter.
-s, --silent
Бесшумный или тихий режим. Не показывать индикатор выполнения или сообщения об ошибках. Делает Curl немым. Он по-прежнему будет выводить запрашиваемые вами данные, возможно, даже на терминал/стандартный вывод, если вы не перенаправите их.
Используйте --show-error в дополнение к этой опции, чтобы отключить индикатор выполнения, но по-прежнему отображать сообщения об ошибках.
Пример:
curl -s https://example.com

См. также -v, --verbose, --stderr и --no-progress-meter.
--socks4 <хост[:порт]>
Использовать указанный прокси-сервер SOCKS4. Если номер порта не указан, предполагается, что это порт 1080. Используя этот тип сокета, заставьте curl разрешить имя хоста и передать адрес прокси.
Чтобы указать прокси в сокете домена unix, используйте localhost для хоста, например. socks4://localhost/путь/к/socket.sock
Этот параметр переопределяет любое предыдущее использование -x, --proxy, поскольку они взаимоисключающие.
Этот параметр является излишним, так как вы можете указать прокси-сервер socks4 с параметром --proxy, используя префикс протокола socks4://.
Начиная с версии 7.52.0, --preproxy можно использовать для указания прокси-сервера SOCKS одновременно с --proxy с прокси-сервером HTTP/HTTPS. В таком случае curl сначала подключается к прокси-серверу SOCKS, а затем подключается (через SOCKS) к прокси-серверу HTTP или HTTPS.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --socks4 имя хоста: 4096 https://example.com

См. также --socks4a, --socks5 и --socks5-hostname.
--socks4a <хост[:порт]>
Использовать указанный прокси-сервер SOCKS4a. Если номер порта не указан, предполагается, что это порт 1080. Это запрашивает прокси-сервер для разрешения имени хоста.
Чтобы указать прокси в сокете домена unix, используйте localhost для хоста, например. socks4a://localhost/путь/к/socket.sock
Этот параметр переопределяет любое предыдущее использование -x, --proxy, поскольку они взаимоисключающие.
Этот параметр является излишним, так как вы можете указать прокси-сервер socks4a с параметром --proxy, используя префикс протокола socks4a://.
Начиная с версии 7.52.0, --preproxy можно использовать для указания прокси-сервера SOCKS одновременно с --proxy с прокси-сервером HTTP/HTTPS. В таком случае curl сначала подключается к прокси-серверу SOCKS, а затем подключается (через SOCKS) к прокси-серверу HTTP или HTTPS.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --socks4a имя хоста: 4096 https://example.com

См. также --socks4, --socks5 и --socks5-hostname.
--socks5-базовый
Указывает curl использовать аутентификацию по имени пользователя/паролю при подключении к прокси-серверу SOCKS5. Аутентификация по имени пользователя/паролю включена по умолчанию. Используйте --socks5-gssapi для принудительной аутентификации GSS-API для прокси-серверов SOCKS5.
Пример:
curl --socks5-basic --socks5 имя хоста: 4096 https://example.com

См. также --socks5. Добавлено в 7.55.0.
--socks5-gssapi-nec
В рамках согласования GSS-API согласовывается режим защиты. RFC 1961 говорится в разделе 4.3/4.4, что он должен быть защищен, но эталонная реализация NEC этого не делает. Параметр --socks5-gssapi-nec разрешает незащищенный обмен согласованием режима защиты.
Пример:
curl --socks5-gssapi-nec --socks5 имя хоста:4096 https://example.com

См. также --socks5.
--socks5-gssapi-service <имя>
Имя службы по умолчанию для socks-сервера — rcmd/server-fqdn. Эта опция позволяет вам изменить его.
Примеры: --socks5 proxy-name --socks5-gssapi-service sockd будет использовать sockd/proxy-name --socks5 proxy-name --socks5-gssapi-service sockd/real-name будет использовать sockd/real-name для случаев, когда прокси-имя не совпадает с основным именем.
Пример:
curl --socks5-gssapi-service sockd --socks5 имя хоста: 4096 https://example.com

См. также --socks5.
--socks5-gssapi
Сообщает curl использовать аутентификацию GSS-API при подключении к прокси-серверу SOCKS5. Аутентификация GSS-API включена по умолчанию (если curl скомпилирован с поддержкой GSS-API). Используйте --socks5-basic для принудительной аутентификации по имени пользователя/паролю для прокси-серверов SOCKS5.
Пример:
curl --socks5-gssapi --socks5 имя хоста: 4096 https://example.com

См. также --socks5. Добавлено в 7.55.0.
--socks5-hostname <хост[:порт]>
Использовать указанный прокси-сервер SOCKS5 (и позволить прокси-серверу разрешать имя хоста). Если номер порта не указан, предполагается, что это порт 1080.
Чтобы указать прокси в сокете домена unix, используйте localhost для хоста, например. socks5h://локальный/путь/к/socket.sock
Этот параметр переопределяет любое предыдущее использование -x, --proxy, поскольку они взаимоисключающие.
Этот параметр является излишним, так как вы можете указать прокси-сервер socks5 hostname с --proxy, используя префикс протокола socks5h://.
Начиная с версии 7.52.0, --preproxy можно использовать для указания прокси-сервера SOCKS, в то время как --proxy используется с прокси-сервером HTTP/HTTPS. В таком случае curl сначала подключается к прокси-серверу SOCKS, а затем подключается (через SOCKS) к прокси-серверу HTTP или HTTPS.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --socks5-hostname proxy.example:7000 https://example.com

См. также --socks5 и --socks4a.
--socks5 <хост[:порт]>
Использовать указанный прокси-сервер SOCKS5, но разрешать имя хоста локально. Если номер порта не указан, предполагается, что это порт 1080.
Чтобы указать прокси в сокете домена unix, используйте localhost для хоста, например. socks5://локальный/путь/к/socket.sock
Этот параметр переопределяет любое предыдущее использование -x, --proxy, поскольку они взаимоисключающие.
Этот параметр является излишним, поскольку вы можете указать прокси-сервер socks5 с параметром --proxy, используя префикс протокола socks5://.
Начиная с версии 7.52.0, --preproxy можно использовать для указания прокси-сервера SOCKS одновременно с --proxy с прокси-сервером HTTP/HTTPS. В таком случае curl сначала подключается к прокси-серверу SOCKS, а затем подключается (через SOCKS) к прокси-серверу HTTP или HTTPS.
Если эта опция используется несколько раз, будет использована последняя.
Эта опция (как и --socks4) не работает с IPV6, FTPS или LDAP.
Пример:
curl --socks5 proxy.example:7000 https://example.com

См. также --socks5-hostname и --socks4a.
-Y, --speed-limit <скорость>
Если передача медленнее, чем заданная скорость (в байтах в секунду) в течение скорости-времени в секундах, она прерывается. скорость-время устанавливается с помощью --speed-time и равна 30, если не установлена.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --speed-limit 300 --speed-time 10 https://example.com

См. также -y, --speed-time, --limit-rate и -m, --max-time.
-y, --speed-time <секунды>
Если передача выполняется медленнее, чем ограничение скорости в байтах в секунду в течение периода времени скорости, передача прерывается. Если используется скорость-время, ограничение скорости по умолчанию будет равно 1, если только оно не установлено с помощью -Y, --speed-limit.
Этот параметр управляет передачей (в обоих направлениях), но не влияет на медленные соединения и т. д. Если вас это беспокоит, попробуйте параметр --connect-timeout.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --speed-limit 300 --speed-time 10 https://example.com

См. также -Y, --speed-limit и --limit-rate.
--ssl-разрешить-зверь
Этот параметр сообщает curl, что не следует обходить уязвимость в безопасности протоколов SSL3 и TLS1.0, известную как BEAST. Если этот параметр не используется, уровень SSL может использовать обходные пути, о которых известно, что они вызывают проблемы совместимости с некоторыми старыми реализациями SSL.
ПРЕДУПРЕЖДЕНИЕ: эта опция ослабляет безопасность SSL, и, используя этот флаг, вы запрашиваете именно это.
Пример:
curl --ssl-allow-beast https://example.com

См. также --proxy-ssl-allow-beast и -k, --insecure.
--ssl-авто-клиент-сертификат
Укажите libcurl автоматически находить и использовать сертификат клиента для аутентификации по запросу сервера. Этот параметр поддерживается только для Schannel (собственная библиотека Windows SSL). До версии 7.77.0 это было поведением по умолчанию в libcurl с Schannel. Поскольку сервер может запросить любой сертификат, который поддерживает аутентификацию клиента в хранилище сертификатов ОС, это может быть нарушением конфиденциальности и неожиданным.
Пример:
curl --ssl-auto-client-cert https://example.com

См. также --proxy-ssl-auto-client-cert. Добавлено в 7.77.0.
--ssl-без отзыва
(Schannel) Этот параметр указывает curl отключить проверку отзыва сертификата. ВНИМАНИЕ: эта опция ослабляет безопасность SSL, и, используя этот флаг, вы запрашиваете именно это.
Пример:
curl --ssl-no-revoke https://example.com

См. также --crlfile. Добавлено в 7.44.0.
--ssl-запрос
(FTP IMAP POP3 SMTP LDAP) Для соединения требуется SSL/TLS. Разрывает соединение, если сервер не поддерживает SSL/TLS.
Этот параметр обрабатывается в LDAP, начиная с версии 7.81.0. Он полностью поддерживается бэкэндом OpenLDAP и отвергается универсальным бэкэндом ldap, если требуется явный TLS.
Ранее этот параметр назывался --ftp-ssl-reqd.
Пример:
curl --ssl-reqd ftp://example.com

См. также --ssl и -k, --insecure.
--ssl-отозвать-максимальные усилия
(Schannel) Этот параметр указывает curl игнорировать проверки отзыва сертификатов, если они не пройдены из-за отсутствия или отсутствия точек распространения для контрольных списков отзыва.
Пример:
curl --ssl-revoke-best-effort https://example.com

См. также --crlfile и -k, --insecure. Добавлено в 7.70.0.
--ssl
(FTP IMAP POP3 SMTP LDAP) Предупреждение: этот вариант считается небезопасным. Рассмотрите возможность использования --ssl-reqd вместо этого, чтобы быть уверенным, что curl обновится до безопасного соединения.
Попробуйте использовать SSL/TLS для соединения. Возвращается к незащищенному соединению, если сервер не поддерживает SSL/TLS. См. также --ftp-ssl-control и --ssl-reqd для различных уровней требуемого шифрования.
Этот параметр обрабатывается в LDAP, начиная с версии 7.81.0. Он полностью поддерживается бэкендом OpenLDAP и игнорируется универсальным бэкендом ldap.
Обратите внимание, что сервер может закрыть соединение, если согласование не удалось.
Ранее этот параметр назывался --ftp-ssl. Это имя опции все еще можно использовать, но оно будет удалено в будущей версии.
Пример:
curl --ssl pop3://example.com/

См. также --ssl-reqd, -k, --insecure и --ciphers.
-2, --sslv2
(SSL) Эта опция ранее запрашивала у curl использование SSLv2, но, начиная с curl 7.77.0, эта инструкция игнорируется. SSLv2 считается небезопасным (см. RFC 6176).
Пример:
завиток --sslv2 https://example.com

См. также --http1.1 и --http2. -2, --sslv2 требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Эта опция взаимоисключающая для -3, --sslv3 и -1, --tlsv1 и --tlsv1.1 и --tlsv1.2.
-3, --sslv3
(SSL) Эта опция ранее запрашивала у curl использование SSLv3, но, начиная с curl 7. 77.0, эта инструкция игнорируется. SSLv3 считается небезопасным (см. RFC 7568).
Пример:
завиток --sslv3 https://example.com

См. также --http1.1 и --http2. -3, --sslv3 требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Эта опция взаимоисключающая для -2, --sslv2 и -1, --tlsv1 и --tlsv1.1 и --tlsv1.2.
--stderr <файл>
Вместо этого перенаправить все записи в stderr в указанный файл. Если имя файла представляет собой простой «-», вместо этого оно записывается в стандартный вывод.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --stderr output.txt https://example.com

См. также -v, --verbose и -s, --silent.
--стилизованный-выход
Включает автоматическое использование жирного шрифта при записи заголовков HTTP на терминал. Используйте --no-styled-output, чтобы отключить их.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl --styled-output -I https://example.com

См. также -I, --head и -v, --verbose. Добавлено в 7.61.0.
--suppress-connect-headers
Когда используется --proxytunnel и делается запрос CONNECT, не выводить заголовки ответа CONNECT прокси-сервера. Эта опция предназначена для использования с --dump-header или --include, которые используются для отображения заголовков протоколов в выводе. Это не влияет на параметры отладки, такие как --verbose или --trace, или любую статистику.
Пример:
curl --suppress-connect-headers --include -x proxy https://example.com

См. также -D, --dump-header, -i, --include и -p, --proxytunnel. Добавлено в 7.54.0.
--tcp-fastopen
Включить использование TCP Fast Open (RFC7413).
Пример:
curl --tcp-fastopen https://example. com

См. также --false-start. Добавлено в 7.49.0.
--tcp-узел задержки
Включите параметр TCP_NODELAY. См. справочную страницу curl_easy_setopt(3) для получения подробной информации об этой опции.
Начиная с версии 7.50.2, curl устанавливает этот параметр по умолчанию, и вам необходимо явно отключить его, если вы не хотите его включать.
Пример:
curl --tcp-nodelay https://example.com

См. также -N, --no-buffer.
-t, --telnet-option
Параметры передачи в протокол telnet. Поддерживаемые параметры:
TTYPE= Задает тип терминала.
XDISPLOC=<отображение X> Устанавливает местоположение отображения X.
NEW_ENV= Задает переменную среды.
Пример:
curl -t TTYPE=vt100 telnet://example.com/

См. также -K, --config.
--tftp-blksize <значение>
(TFTP) Установите параметр TFTP BLKSIZE (должен быть >512). Это размер блока, который curl попытается использовать при передаче данных на сервер TFTP или с него. По умолчанию будет использоваться 512 байт.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --tftp-blksize 1024 tftp://example.com/file

См. также --tftp-no-options.
--tftp-без параметров
(TFTP) Сообщает curl не отправлять запросы параметров TFTP.
Этот параметр улучшает взаимодействие с некоторыми устаревшими серверами, которые не подтверждают или не реализуют должным образом параметры TFTP. При использовании этой опции параметр --tftp-blksize игнорируется.
Пример:
curl --tftp-без параметров tftp://192.168.0.1/

См. также --tftp-blksize. Добавлено в 7.48.0.
-z, --time-cond <время>
(HTTP FTP) Запросить файл, который был изменен позже указанного времени и даты, или файл, который был изменен до этого времени. <выражение даты> может быть любым видом строк даты или, если оно не совпадает ни с одним из внутренних, оно берется как имя файла и вместо этого пытается получить дату модификации (mtime) из <файла>. См. man-страницы curl_getdate(3) для деталей выражения даты.
Начните выражение даты с тире (-), чтобы запросить документ, который старше указанной даты/времени, по умолчанию используется документ, который новее указанной даты/времени.
Если эта опция используется несколько раз, будет использована последняя.
Примеры:
curl -z "Среда, 01 сентября 2021 г., 12:18:00" https://example.com
curl -z "-Ср, 01 сентября 2021 г., 12:18:00" https://example.com
файл curl -z https://example.com

См. также --etag-compare и -R, --remote-time.
--tls-max <ВЕРСИЯ>
(SSL) VERSION определяет максимальную поддерживаемую версию TLS. Минимально допустимая версия устанавливается tlsv1.0, tlsv1.1, tlsv1.2 или tlsv1.3.
Если подключение выполняется без TLS, этот параметр не действует. Сюда входят переводы с использованием QUIC (HTTP/3).
по умолчанию
Используйте до рекомендуемой версии TLS.
1,0
Используйте до TLSv1. 0.
1.1
Используйте до TLSv1.1.
1.2
Используйте до TLSv1.2.
1.3
Используйте до TLSv1.3.
Примеры:
curl --tls-max 1.2 https://example.com
curl --tls-max 1.3 --tlsv1.2 https://example.com

См. также --tlsv1.0, --tlsv1.1, --tlsv1.2 и --tlsv1.3. --tls-max требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Добавлено в 7.54.0.
--tls13-ciphers <список наборов шифров>
(TLS) Указывает, какие наборы шифров использовать в соединении, если оно согласовывает TLS 1.3. В списке наборов шифров должны быть указаны допустимые шифры. Ознакомьтесь с информацией о наборе шифров TLS 1.3 по этому URL-адресу:
https://curl.se/docs/ssl-ciphers.html

Этот параметр в настоящее время используется только в том случае, если curl создан для использования OpenSSL 1.1.1 или более поздней версии. Если вы используете другую серверную часть SSL, вы можете попробовать установить наборы шифров TLS 1. 3, используя параметр --ciphers.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --tls13-ciphers TLS_AES_128_GCM_SHA256 https://example.com

См. также --шифры и --кривые. Добавлено в 7.61.0.
--tlsauthtype <тип>
Установить тип аутентификации TLS. В настоящее время поддерживается только вариант «SRP» для TLS-SRP (RFC 5054). Если --tlsuser и --tlspassword указаны, а --tlsauthtype нет, то этот параметр по умолчанию равен "SRP". Этот параметр работает только в том случае, если базовый libcurl создан с поддержкой TLS-SRP, для чего требуется OpenSSL или GnuTLS с поддержкой TLS-SRP.
Пример:
curl --tlsauthtype SRP https://example.com

См. также --tlsuser.
--tlspassword <строка>
Установите пароль для использования с методом аутентификации TLS, указанным с --tlsauthtype. Требуется, чтобы --tlsuser также был установлен.
Этот параметр не работает с TLS 1. 3.
Пример:
curl --tlspassword pwd --tlsuser пользователь https://example.com

См. также --tlsuser.
--tlsuser <имя>
Установите имя пользователя для использования с методом аутентификации TLS, указанным с --tlsauthtype. Требуется, чтобы --tlspassword также был установлен.
Этот параметр не работает с TLS 1.3.
Пример:
curl --tlspassword pwd --tlsuser пользователь https://example.com

См. также --tlspassword.
--tlsv1.0
(TLS) Заставляет curl использовать TLS версии 1.0 или выше при подключении к удаленному серверу TLS.
В старых версиях curl этот параметр был задокументирован для разрешения _только_ TLS 1.0. Это поведение было непоследовательным в зависимости от библиотеки TLS. Используйте --tls-max, если вы хотите установить максимальную версию TLS.
Пример:
curl --tlsv1.0 https://example.com

См. также --tlsv1.3. Добавлено в 7.34.0.
--tlsv1. 1
(TLS) Заставляет curl использовать TLS версии 1.1 или выше при подключении к удаленному серверу TLS.
В старых версиях curl этот параметр был задокументирован для разрешения _только_ TLS 1.1. Это поведение было непоследовательным в зависимости от библиотеки TLS. Используйте --tls-max, если вы хотите установить максимальную версию TLS.
Пример:
curl --tlsv1.1 https://example.com

См. также --tlsv1.3 и --tls-max. Добавлено в 7.34.0.
--tlsv1.2
(TLS) Заставляет curl использовать TLS версии 1.2 или выше при подключении к удаленному серверу TLS.
В старых версиях curl этот параметр был задокументирован для разрешения _только_ TLS 1.2. Это поведение было непоследовательным в зависимости от библиотеки TLS. Используйте --tls-max, если вы хотите установить максимальную версию TLS.
Пример:
curl --tlsv1.2 https://example.com

См. также --tlsv1.3 и --tls-max. Добавлено в 7.34.0.
--tlsv1. 3
(TLS) Заставляет curl использовать TLS версии 1.3 или более поздней версии при подключении к удаленному серверу TLS.
Если подключение выполняется без TLS, этот параметр не действует. Сюда входят переводы с использованием QUIC (HTTP/3).
Обратите внимание, что TLS 1.3 поддерживается не всеми серверными частями TLS.
Пример:
curl --tlsv1.3 https://example.com

См. также --tlsv1.2 и --tls-max. Добавлено в 7.52.0.
-1, --tlsv1
(SSL) Сообщает curl использовать по крайней мере версию TLS 1.x при согласовании с удаленным сервером TLS. Это означает, что TLS версии 1.0 или выше
Пример:
завиток --tlsv1 https://example.com

См. также --http1.1 и --http2. -1, --tlsv1 требует, чтобы базовая библиотека libcurl была создана для поддержки TLS. Эта опция взаимоисключающая для --tlsv1.1 и --tlsv1.2 и --tlsv1.3.
--tr-кодирование
(HTTP) Запросить сжатый ответ Transfer-Encoding с использованием одного из алгоритмов, поддерживаемых curl, и распаковать данные при их получении.
Пример:
curl --tr-encoding https://example.com

См. также --сжатый.
--trace-ascii <файл>
Включает полную трассировку всех входящих и исходящих данных, включая описательную информацию, в указанный выходной файл. Используйте «-» в качестве имени файла, чтобы выходные данные отправлялись на стандартный вывод.
Это похоже на --trace, но пропускает шестнадцатеричную часть и показывает только ASCII-часть дампа. Это делает меньший вывод, который может быть легче читать неподготовленным людям.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --trace-ascii log.txt https://example.com

См. также -v, --verbose и --trace. Эта опция взаимоисключающая для --trace и -v, --verbose.
--время трассировки
Добавляет отметку времени к каждой трассировке или подробной строке, отображаемой curl.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Пример:
curl --trace-time --trace-ascii вывод https://example.com

См. также --trace и -v, --verbose.
--trace <файл>
Включает полную трассировку всех входящих и исходящих данных, включая описательную информацию, в указанный выходной файл. Используйте «-» в качестве имени файла, чтобы выходные данные отправлялись на стандартный вывод. Используйте «%» в качестве имени файла, чтобы выходные данные отправлялись в stderr.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl --trace log.txt https://example.com

См. также --trace-ascii и --trace-time. Эта опция взаимоисключающая для -v, --verbose и --trace-ascii.
--unix-сокет <путь>
(HTTP) Подключитесь через этот сокет домена Unix вместо использования сети.
Пример:
curl --unix-socket путь-сокета https://example.com

См. также --abstract-unix-socket. Добавлено в 7.40.0.
-T, --upload-file <файл>
Переносит указанный локальный файл на удаленный URL-адрес. Если в указанном URL-адресе нет файловой части, curl добавит имя локального файла. ЗАМЕТЬТЕ, что вы должны использовать конечный / в последнем каталоге, чтобы действительно доказать Curl, что имени файла нет, иначе curl будет думать, что ваше последнее имя каталога является именем удаленного файла для использования. Это, скорее всего, приведет к сбою операции загрузки. Если это используется на сервере HTTP(S), будет использована команда PUT.
Используйте имя файла "-" (одиночное тире), чтобы использовать стандартный ввод вместо данного файла. В качестве альтернативы имя файла "." (один период) может быть указан вместо «-», чтобы использовать стандартный ввод в неблокирующем режиме, чтобы разрешить чтение вывода сервера во время загрузки стандартного ввода.
Вы можете указать один --upload-file для каждого URL-адреса в командной строке. Каждая пара -T, --upload-file + URL указывает, что и куда загружать. curl также поддерживает «подстановку» аргумента --upload-file, что означает, что вы можете загружать несколько файлов на один URL-адрес, используя тот же стиль подстановки URL-адресов, который поддерживается в URL-адресе.
При загрузке на SMTP-сервер: предполагается, что загруженные данные имеют формат RFC 5322. Он должен содержать необходимый набор заголовков и тело письма, правильно отформатированное пользователем, поскольку curl не будет ни перекодировать, ни кодировать его дальше.
Примеры:
curl -T файл https://example.com
curl -T "img[1-1000].png" ftp://ftp.example.com/
curl --upload-file "{file1,file2}" https://example.com

См. также -G, --get и -I, --head.
--url <ссылка>
Укажите URL-адрес для получения. Эта опция в основном удобна, когда вы хотите указать URL-адреса в файле конфигурации.
Если в указанном URL-адресе отсутствует имя схемы (например, «http://» или «ftp://» и т. д.), curl сделает предположение на основе хоста. Если имя самого внешнего поддомена соответствует DICT, FTP, IMAP, LDAP, POP3 или SMTP, то будет использоваться этот протокол, в противном случае будет использоваться HTTP. Поскольку угадывание 7.45.0 можно отключить, установив протокол по умолчанию, подробности см. в разделе --proto-default.
Эту опцию можно использовать любое количество раз. Чтобы контролировать, где этот URL-адрес написан, используйте параметры --output или --remote-name.
ПРЕДУПРЕЖДЕНИЕ. В Windows определенные обращения к файлу:// могут быть преобразованы операционной системой в сетевые обращения. Остерегаться!
Пример:
curl --url https://example.com

См. также -:, --next и -K, --config.
-B, --use-ascii
(FTP LDAP) Включить передачу ASCII. Для FTP это также может быть реализовано с помощью URL-адреса, оканчивающегося на «;type=A». Этот параметр заставляет данные, отправляемые на стандартный вывод, быть в текстовом режиме для систем win32.
Пример:
curl -B ftp://example.com/README

См. также --crlf и --data-ascii.
-A, --user-agent <имя>
(HTTP) Укажите строку User-Agent для отправки на HTTP-сервер. Чтобы закодировать пробелы в строке, заключите строку в одинарные кавычки. Этот заголовок также можно установить с помощью параметров --header или --proxy-header.
Если вы укажете пустой аргумент -A, --user-agent (""), он полностью удалит заголовок из запроса. Если вы предпочитаете пустой заголовок, вы можете установить его на один пробел ("").
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl -A "Агент 007" https://example.com

См. также -H, --header и --proxy-header.
-u, --user <пользователь:пароль>
Укажите имя пользователя и пароль для проверки подлинности сервера. Переопределяет --netrc и --netrc-необязательный.
Если вы просто укажете имя пользователя, curl запросит пароль.
Имя пользователя и пароли разделены первым двоеточием, что делает невозможным использование двоеточия в имени пользователя с этой опцией. Может, еще пароль.
В системах, где это работает, curl будет скрывать данный аргумент опции из листингов процессов. Этого недостаточно для защиты учетных данных от возможного просмотра другими пользователями в той же системе, поскольку они все еще будут видны некоторое время, прежде чем будут очищены. Такие конфиденциальные данные следует извлекать из файла или аналогичного файла и никогда не использовать в виде открытого текста в командной строке.
При использовании Kerberos V5 с сервером на базе Windows вы должны включить доменное имя Windows в имя пользователя, чтобы сервер мог успешно получить билет Kerberos. Если вы этого не сделаете, начальное рукопожатие аутентификации может завершиться ошибкой.
При использовании NTLM имя пользователя может быть указано просто как имя пользователя без домена, если, например, в вашей настройке есть один домен и лес.
Чтобы указать имя домена, используйте формат имени для входа нижнего уровня или имя участника-пользователя (UPN). Например, EXAMPLE\user и [email protected] соответственно.
Если вы используете двоичный файл curl с поддержкой Windows SSPI и выполняете аутентификацию Kerberos V5, Negotiate, NTLM или Digest, вы можете указать curl выбрать имя пользователя и пароль из вашей среды, указав одно двоеточие с этой опцией: "-u :".
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl -u пользователь: секрет https://example.com

См. также -n, --netrc и -K, --config.
-v, --verbose
Делает curl подробным во время операции. Полезно для отладки и просмотра того, что происходит «под капотом». Строка, начинающаяся с «>», означает «данные заголовка», отправленные curl, «<» означает «данные заголовка», полученные curl, которые в обычных случаях скрыты, а строка, начинающаяся с «*», означает дополнительную информацию, предоставленную curl.
Если вам нужны только заголовки HTTP в выводе, --include может быть тем параметром, который вам нужен.
Если вы считаете, что эта опция по-прежнему не дает вам достаточно подробностей, рассмотрите возможность использования вместо нее --trace или --trace-ascii.
Этот параметр является глобальным, и его не нужно указывать для каждого использования -:, --next.
Используйте --silent, чтобы сделать curl действительно тихим.
Пример:
curl --verbose https://example.com

См. также -i, --include. Эта опция взаимоисключающая для --trace и --trace-ascii.
-V, --версия
Отображает информацию о curl и используемой версии libcurl.
Первая строка включает полную версию curl, libcurl и других сторонних библиотек, связанных с исполняемым файлом.
Вторая строка (начинается с "Protocols:") показывает все протоколы, которые libcurl поддерживает.
Третья строка (начинается с «Features:») показывает конкретные функции, которые предлагает отчет libcurl. Доступные функции включают в себя:
альт-SVC
Обеспечивается поддержка заголовка Alt-Svc:.
АсинхДНС
Этот завиток использует асинхронное разрешение имен. Асинхронное преобразование имен может быть выполнено с использованием серверной части c-ares или многопоточного преобразователя.
Бротли
Поддержка автоматического сжатия brotli через HTTP(S).
ЧарКонв
curl был создан с поддержкой преобразования набора символов (например, EBCDIC)
Отладка
Этот curl использует libcurl, созданный с помощью Debug. Это позволяет лучше отслеживать ошибки, отлаживать память и т. д. Только для curl-разработчиков!
гсасл
Встроенная аутентификация SASL включает расширения для поддержки SCRAM, поскольку libcurl был создан с использованием libgsasl.
GSS-API
GSS-API поддерживается.
ХСТС
Поддержка HSTS присутствует.
HTTP2
Встроена поддержка HTTP/2.
HTTP3
Встроена поддержка HTTP/3.
HTTPS-прокси
Этот завиток создан для поддержки HTTPS-прокси.
ИДН
Этот curl поддерживает IDN — международные доменные имена.
IPv6
С этим можно использовать IPv6.
Керберос
Поддерживается проверка подлинности Kerberos V5.
Большой файл
Этот завиток поддерживает передачу больших файлов, файлов размером более 2 ГБ.
либз
Поддерживается автоматическая распаковка (через gzip, deflate) сжатых файлов через HTTP.
МультиSSL
Этот curl поддерживает несколько серверных частей TLS.
НТЛМ
Поддерживается проверка подлинности NTLM.
NTLM_WB
Поддерживается делегирование NTLM помощнику winbind.
ПСЛ
PSL является сокращением от Public Suffix List и означает, что этот завиток был создан с учетом «общедоступных суффиксов».
СПНЕГО
Поддерживается аутентификация SPNEGO.
SSL
Поддерживаются версии SSL различных протоколов, таких как HTTPS, FTPS, POP3S и так далее.
ССПИ
SSPI поддерживается.
ТЛС-СРП
Аутентификация SRP (Secure Remote Password) поддерживается для TLS.
Трековая память
Отслеживание памяти отладки поддерживается.
Юникод
Поддержка Unicode в Windows.
UnixSockets
Обеспечена поддержка сокетов Unix.
зстд
Поддерживается автоматическая распаковка (через zstd) сжатых файлов через HTTP.
Пример:
завиток --версия

См. также -h, --help и -M, --manual.
-w, --write-out <формат>
Заставить curl отображать информацию на стандартный вывод после завершения передачи. Формат представляет собой строку, которая может содержать обычный текст, смешанный с любым количеством переменных. Формат может быть указан как буквальная «строка», или вы можете заставить curl прочитать формат из файла с «@filename» и сказать curl прочитать формат из стандартного ввода, вы пишете «@-».
Переменные, представленные в выходном формате, будут заменены значением или текстом, который curl считает нужным, как описано ниже. Все переменные указаны как %{имя_переменной}, и для вывода обычного % вы просто записываете их как %%. Вы можете вывести новую строку, используя \n, возврат каретки с помощью \r и пробел с помощью \t.
Вывод будет записан в стандартный вывод, но его можно переключить на стандартную ошибку с помощью %{stderr}.
Вывод заголовков HTTP из самого последнего запроса с использованием %header{name}, где name — имя заголовка без учета регистра (без двоеточия в конце). Содержимое заголовка точно такое же, как при отправке по сети, с обрезанными начальными и конечными пробелами. Добавлено в curl 7.84.0.
ПРИМЕЧАНИЕ. Символ % — это специальный символ в среде win32, где все вхождения % должны удваиваться при использовании этой опции.
Доступны следующие переменные:
content_type Тип содержимого запрошенного документа, если таковой имеется.
errormsg Сообщение об ошибке. (Добавлено в 7.75.0)
код выхода Числовой код выхода перевода. (Добавлено в 7.75.0)
имя_файла_эффективное Окончательное имя файла, в который записывается curl. Это имеет смысл только в том случае, если curl указано записать в файл с опцией --remote-name или --output. Это наиболее полезно в сочетании с опцией --remote-header-name.
ftp_entry_path Исходный путь curl закончился при входе на удаленный FTP-сервер.
header_json Объект JSON со всеми заголовками ответов HTTP из последней передачи. Значения предоставляются в виде массивов, поскольку в случае нескольких заголовков может быть несколько значений.
Имена заголовков, указанные строчными буквами, перечислены в порядке появления в сети. За исключением повторяющихся заголовков. Они сгруппированы по первому вхождению этого заголовка, каждое значение представлено в массиве JSON.
http_code Числовой код ответа, обнаруженный в последней полученной передаче HTTP(S) или FTP(s).
http_connect Числовой код, найденный в последнем ответе (от прокси-сервера) на запрос curl CONNECT.
http_version Эффективно используемая версия http. (Добавлено в 7.50.0)
json Объект JSON со всеми доступными ключами.
local_ip IP-адрес локального конца последнего установленного соединения — может быть либо IPv4, либо IPv6.
local_port Номер локального порта последнего установленного соединения.
method Метод http, использованный в последнем HTTP-запросе. (Добавлено в 7.72.0)
num_connects Количество новых подключений, выполненных при последней передаче.
num_headers Количество заголовков ответа в самом последнем запросе (перезапущенном при каждом перенаправлении). Обратите внимание, что строка состояния НЕ ЯВЛЯЕТСЯ заголовком. (Добавлено в 7.73.0)
num_redirects Количество перенаправлений, которые были выполнены в запросе.
onerror Остальная часть вывода отображается только в том случае, если передача вернула ненулевую ошибку (добавлено в 7. 75.0)
proxy_ssl_verify_result Результат запрошенной проверки однорангового SSL-сертификата прокси-сервера HTTPS. 0 означает, что проверка прошла успешно. (Добавлено в 7.52.0)
redirect_url Когда HTTP-запрос был сделан без --location для следования перенаправлениям (или когда --max-redirs выполняется), эта переменная покажет фактический URL-адрес, на который было бы направлено перенаправление.
referer Заголовок Referer:, если он есть. (Добавлено в 7.76.0)
remote_ip Удаленный IP-адрес последнего установленного соединения — может быть либо IPv4, либо IPv6.
remote_port Номер удаленного порта последнего установленного соединения.
response_code Числовой код ответа, обнаруженный при последней передаче (ранее известный как «http_code»).
схема Эффективно использованная схема URL (иногда называемая протоколом). (Добавлено в 7.52.0)
size_download Общее количество загруженных байтов. Это размер тела/данных, которые были переданы, за исключением заголовков.
size_header Общий объем загруженных заголовков в байтах.
size_request Общее количество байтов, отправленных в HTTP-запросе.
size_upload Общее количество загруженных байтов. Это размер тела/данных, которые были переданы, за исключением заголовков.
speed_download Средняя скорость загрузки, измеренная curl для полной загрузки. Байт в секунду.
speed_upload Средняя скорость загрузки, измеренная curl для полной загрузки. Байт в секунду.
ssl_verify_result Результат запрошенной проверки однорангового сертификата SSL. 0 означает, что проверка прошла успешно.
stderr С этого момента вывод --write-out будет записываться в стандартную ошибку. (Добавлено в 7.63.0)
stdout С этого момента вывод --write-out будет записываться в стандартный вывод. Это значение по умолчанию, но его можно использовать для обратного переключения после переключения на stderr. (Добавлено в 7.63.0)
time_appconnect Время в секундах, прошедшее от начала до завершения SSL/SSH/и т. д. соединения/рукопожатия с удаленным хостом.
time_connect Время в секундах, прошедшее от начала до завершения соединения TCP с удаленным хостом (или прокси).
time_namelookup Время в секундах, прошедшее от начала до завершения разрешения имени.
time_pretransfer Время в секундах, прошедшее от начала до момента начала передачи файла. Это включает в себя все команды и согласования перед передачей, которые относятся к конкретному задействованному протоколу (протоколам).
time_redirect Время в секундах, затраченное на все этапы перенаправления, включая поиск имени, подключение, предварительную передачу и передачу, прежде чем была запущена окончательная транзакция. time_redirect показывает полное время выполнения нескольких перенаправлений.
time_starttransfer Время в секундах, прошедшее от начала до момента, когда должен был быть передан первый байт. Сюда входит time_pretransfer, а также время, необходимое серверу для вычисления результата.
time_total Общее время в секундах, в течение которого длилась полная операция.
url Полученный URL. (Добавлено в 7.75.0)
urlnum Индексный номер URL этой передачи, с индексом 0. URL-адреса с преобразованием подстановки имеют тот же номер индекса, что и исходный URL-адрес с подстановкой. (Добавлено в 7.75.0)
url_efficient URL-адрес, который был выбран последним. Это наиболее важно, если вы сказали curl следовать по адресу: headers.
Если эта опция используется несколько раз, будет использована последняя.
Пример:
curl -w '%{http_code}\n' https://example.com

См. также -v, --verbose и -I, --head.
--xattr
При сохранении вывода в файл этот параметр указывает curl сохранять определенные метаданные файла в расширенных атрибутах файла. В настоящее время URL-адрес хранится в атрибуте xdg.origin.url, а для HTTP тип контента хранится в атрибуте mime_type. Если файловая система не поддерживает расширенные атрибуты, выдается предупреждение.
Пример:
curl --xattr -o хранилище https://example. com

См. также -R, --remote-time, -w, --write-out и -v, --verbose.
Файлы
~/.curlrc
Конфигурационный файл по умолчанию, подробности см. в --config.
Окружающая среда
Переменные среды могут быть указаны в нижнем или верхнем регистре. Версия нижнего регистра имеет приоритет. http_proxy является исключением, так как он доступен только в нижнем регистре.
Использование переменной среды для установки прокси имеет тот же эффект, что и использование параметра --proxy.
http_proxy [протокол://]<хост>[:порт]
Задает прокси-сервер, который будет использоваться для HTTP.
HTTPS_PROXY [протокол://]<хост>[:порт]
Задает прокси-сервер, который будет использоваться для HTTPS.
[url-протокол]_PROXY [протокол://]<хост>[:порт]
Устанавливает прокси-сервер для использования для [url-protocol], где протокол — это протокол, который поддерживает curl и указанный в URL-адресе. FTP, FTPS, POP3, IMAP, SMTP, LDAP и т. д.
ALL_PROXY [протокол://]<хост>[:порт]
Задает прокси-сервер, который будет использоваться, если не задан прокси-сервер для конкретного протокола.
NO_PROXY <список хостов/доменов через запятую>
список имен хостов, которые не должны проходить через прокси. Если установлено только звездочка '*', оно соответствует всем хостам. Каждое имя в этом списке сопоставляется либо как доменное имя, содержащее имя хоста, либо как само имя хоста.
Эта переменная среды отключает использование прокси, даже если она указана с параметром --proxy. То есть NO_PROXY=direct.example.com curl -x http://proxy.example.com http://direct.example.com обращается к целевому URL напрямую, а NO_PROXY=direct.example.com curl -x http:/ /proxy.example.com http://somewhere.example.com обращается к целевому URL-адресу через прокси-сервер.
Список имен хостов также может включать числовые IP-адреса, а версии IPv6 следует указывать без квадратных скобок.
Числовые адреса IPv6 сравниваются как строки, поэтому они будут совпадать только в том случае, если представления совпадают: "::1" совпадает с "::0:1", но они не совпадают.
ПРИЛОЖЕНИЕ <каталог>
В Windows эта переменная используется при попытке найти домашний каталог. Если первичная домашняя переменная не установлена.
КОЛОННЫ <ширина терминала>
Если установлено, указанное количество символов будет использоваться в качестве ширины терминала при отображении альтернативного индикатора выполнения. Если не установлено, curl попытается выяснить это другими способами.
CURL_CA_BUNDLE <файл>
Если установлено, будет использоваться как значение --cacert.
CURL_HOME <каталог>
Если установлено, это первая переменная, которую curl проверяет при попытке найти свой домашний каталог. Если не установлено, он продолжает проверять XDG_CONFIG_HOME.
CURL_SSL_BACKEND <серверная часть TLS>
Если curl был создан с поддержкой «MultiSSL», что означает, что он имеет встроенную поддержку более чем одного бэкэнда TLS, эта переменная среды может быть установлена на нечувствительное к регистру имя конкретного бэкэнда, которое будет использоваться при вызове curl. Установка имени, которое не является встроенной альтернативой, приведет к тому, что curl останется по умолчанию.
Имена серверных частей SSL (без учета регистра): bearssl, gnutls, gskit, mbedtls, nss, openssl, rustls, schannel, secure-transport, wolfssl
ГЛАВНАЯ <каталог>
Если установлено, используется для поиска домашнего каталога, когда это необходимо. Например, при поиске стандартного .curlrc. CURL_HOME и XDG_CONFIG_HOME имеют предпочтение.
QLOGDIR <имя каталога>
Если curl был создан с поддержкой HTTP/3, установка этой переменной среды в локальный каталог заставит curl создавать qlogs в этом каталоге, используя имена файлов, названные в соответствии с идентификатором целевого соединения (в шестнадцатеричном формате). Обратите внимание, что эти файлы могут стать довольно большими. Работает с обоими бэкендами QUIC.
ОБОЛОЧКА
Используется в VMS при попытке определить, используется ли оболочка DCL или «unix».
SSL_CERT_DIR <каталог>
Если установлено, будет использоваться как значение --capath.
SSL_CERT_FILE <путь>
Если установлено, будет использоваться как значение --cacert.
SSLKEYLOGFILE <имя файла>
Если вы установите для этой переменной среды имя файла, curl будет сохранять секреты TLS от своих соединений в этом файле при вызове, чтобы вы могли анализировать трафик TLS в режиме реального времени с помощью инструментов сетевого анализа, таких как Wireshark. Это работает со следующими бэкендами TLS: OpenSSL, libressl, BoringSSL, GnuTLS, NSS и wolfSSL.
ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ <каталог>
В Windows эта переменная используется при попытке найти домашний каталог. Если другая, первичная, переменная не установлена. Если установлено, curl будет использовать путь "$USERPROFILE\Application Data".
XDG_CONFIG_HOME <каталог>
Если CURL_HOME не задан, эта переменная проверяется при поиске файла .curlrc по умолчанию.
Префиксы протоколов прокси
Строка прокси может быть указана с префиксом protocol:// для указания альтернативных протоколов прокси.
Если в строке прокси не указан протокол или строка не совпадает с поддерживаемой, прокси будет рассматриваться как HTTP прокси.
Поддерживаемые префиксы протокола прокси:
http://
Позволяет использовать его в качестве HTTP-прокси. Значение по умолчанию, если префикс схемы не используется.
https://
Делает его прокси-сервером HTTPS.
носки4://
Делает его эквивалентным --socks4
socks4a://
Делает его эквивалентным --socks4a
носки5://
Делает его эквивалентным --socks5
носки5h://
Делает его эквивалентным --socks5-hostname
Коды выхода
Существует множество различных кодов ошибок и соответствующих им сообщений об ошибках, которые могут появляться в условиях ошибки. На момент написания этой статьи коды выхода были такими:
0
Успех. Операция прошла успешно согласно инструкции.
1
Неподдерживаемый протокол. Эта сборка curl не поддерживает этот протокол.
2
Не удалось инициализировать.
3
Неверный формат URL-адреса. Синтаксис был неправильным.
4
Функция или параметр, необходимые для выполнения требуемого запроса, не были включены или были явно отключены во время сборки. Чтобы заставить curl сделать это, вам, вероятно, понадобится другая сборка libcurl.
5
Не удалось разрешить прокси. Данный прокси-хост не может быть разрешен.
6
Не удалось разрешить хост. Не удалось разрешить данный удаленный хост.
7
Не удалось подключиться к хосту.
8
Странный ответ сервера. Сервер, отправивший данные, не смог выполнить синтаксический анализ.
9
Доступ к FTP запрещен. Сервер отказал в регистрации или доступе к конкретному ресурсу или каталогу, к которому вы хотели получить доступ. Чаще всего вы пытались перейти в каталог, который не существует на сервере.
10
Не удалось принять FTP. Во время ожидания обратного подключения сервера при использовании активного сеанса FTP код ошибки был отправлен по управляющему соединению или аналогичному.
11
FTP странный ответ PASS. Curl не удалось проанализировать ответ, отправленный на запрос PASS.
12
Во время активного сеанса FTP во время ожидания обратного подключения сервера к curl истекло время ожидания.
13
FTP странный ответ PASV, Curl не может проанализировать ответ, отправленный на запрос PASV.
14
FTP странный формат 227. Curl не смог разобрать 227-ю строку, отправленную сервером.
15
FTP не может использовать хост. Не удалось разрешить IP-адрес хоста, который мы получили в строке 227.
16
Ошибка HTTP/2. Обнаружена проблема на уровне кадрирования HTTP2. Это несколько общее и может быть одной из нескольких проблем, подробности см. в сообщении об ошибке.
17
FTP не удалось установить двоичный файл. Не удалось изменить метод передачи на двоичный.
18
Частичный файл. Перенесена только часть файла.
19
FTP не удалось загрузить/доступ к данному файлу, команда RETR (или аналогичная) не удалась.
21
Ошибка цитаты FTP. Команда цитаты вернула ошибку с сервера.
22
HTTP-страница не получена. Запрошенный URL-адрес не найден или вернул другую ошибку с кодом ошибки HTTP 400 или выше. Этот код возврата появляется, только если используется --fail.
23
Ошибка записи. Curl не может записывать данные в локальную файловую систему или что-то подобное.
25
FTP не удалось сохранить файл. Сервер отклонил операцию STOR, используемую для загрузки по FTP.
26
Ошибка чтения. Различные проблемы с чтением.
27
Недостаточно памяти. Не удалось выполнить запрос на выделение памяти.
28
Тайм-аут операции. Указанный период тайм-аута был достигнут в соответствии с условиями.
30
FTP ПОРТ не работает. Не удалось выполнить команду PORT. Не все FTP-серверы поддерживают команду PORT, попробуйте выполнить передачу с помощью PASV!
31
FTP не может использовать REST. Не удалось выполнить команду REST. Эта команда используется для возобновления FTP-передачи.
33
Ошибка диапазона HTTP. Диапазон "команда" не работал.
34
Ошибка отправки HTTP. Внутренняя ошибка формирования пост-запроса.
35
Ошибка соединения SSL. Сбой квитирования SSL.
36
Неверное возобновление загрузки. Не удалось продолжить ранее прерванную загрузку.
37
FILE не удалось прочитать файл. Не удалось открыть файл. Разрешения?
38
LDAP не может выполнить привязку. Сбой операции привязки LDAP.
39
Ошибка поиска LDAP.
41
Функция не найдена. Требуемая функция LDAP не найдена.
42
Прервано обратным вызовом. Приложение приказало curl прервать операцию.
43
Внутренняя ошибка. Функция была вызвана с неверным параметром.
45
Ошибка интерфейса. Не удалось использовать указанный исходящий интерфейс.
47
Слишком много перенаправлений. При следовании перенаправлениям curl достигает максимального значения.
48
Для libcurl указана неизвестная опция. Это указывает на то, что вы передали странную опцию curl, которая была передана libcurl и отклонена. Почитай в мануале!
49
Неверный формат параметра telnet.
52
Сервер ничего не ответил, что здесь считается ошибкой.
53
Механизм шифрования SSL не найден.
54
Невозможно установить механизм шифрования SSL по умолчанию.
55
Ошибка отправки сетевых данных.
56
Сбой при приеме сетевых данных.
58
Проблема с локальным сертификатом.
59
Не удалось использовать указанный шифр SSL.
60
Сертификат узла не может быть аутентифицирован известными сертификатами ЦС.
61
Нераспознанное кодирование передачи.
63
Превышен максимальный размер файла.
64
Запрошенный уровень FTP SSL не выполнен.
65
Для отправки данных требуется повторная перемотка, которая не удалась.
66
Не удалось инициализировать механизм SSL.
67
Имя пользователя, пароль или что-то подобное не были приняты, и curl не удалось войти в систему.
68
Файл не найден на сервере TFTP.
69
Проблема с правами доступа на TFTP-сервере.
70
Недостаточно места на TFTP-сервере.
71
Недопустимая операция TFTP.
72
Неизвестный идентификатор передачи TFTP.
73
Файл уже существует (TFTP).
74
Нет такого пользователя (TFTP).
77
Проблема чтения сертификата SSL CA (путь? права доступа?).
78
Ресурс, указанный в URL-адресе, не существует.
79
Неизвестная ошибка во время сеанса SSH.
80
Не удалось закрыть соединение SSL.
82
Не удалось загрузить файл CRL, он отсутствует или имеет неверный формат.
83
Ошибка проверки эмитента.
84
Не удалось выполнить команду FTP PRET.
85
Несоответствие номеров RTSP CSeq.
86
Несоответствие идентификаторов сеанса RTSP.
87
Невозможно проанализировать список файлов FTP.
88
Обратный вызов фрагмента FTP сообщил об ошибке.
89
Соединение недоступно, сеанс будет поставлен в очередь.
90
Открытый ключ SSL не соответствует закрепленному открытому ключу.
91
Недопустимый статус SSL-сертификата.
92
Ошибка потока на уровне кадрирования HTTP/2.
93
Функция API была вызвана из обратного вызова.
94
Функция проверки подлинности возвратила ошибку.
95
Обнаружена проблема на уровне HTTP/3. Это несколько общее и может быть одной из нескольких проблем, подробности см. в сообщении об ошибке.
96
Ошибка подключения QUIC. Эта ошибка может быть вызвана ошибкой библиотеки SSL. QUIC — это протокол, используемый для передачи HTTP/3.
ХХ
В будущих версиях здесь появятся дополнительные коды ошибок. Существующие никогда не должны меняться.
Ошибки
Если у вас возникли проблемы с curl, отправьте сообщение о проблеме в системе отслеживания ошибок проекта на GitHub: https://github.com/curl/curl/issues
Авторы / участники
Дэниел Стенберг — главный автор , но весь список участников находится в отдельном файле THANKS.
Www
https://curl.se
См. также
ftp(1), wget(1)
Эта HTML-страница была создана с помощью roffit.
HTTP-запросов | Кодакадемия
<noscript><img loading='lazy' src='' /></noscript> youtube.com/embed/-Zea7GB2OwA" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""> Предыстория:
Эта страница создана с помощью сети HTML, CSS и Javascript, отправленной вам Codecademy через Интернет. Интернет состоит из множества ресурсов, размещенных на разных серверах. Термин «ресурс» относится к любому объекту в Интернете, включая файлы HTML, таблицы стилей, изображения, видео и сценарии. Чтобы получить доступ к контенту в Интернете, ваш браузер должен запрашивать у этих серверов необходимые ему ресурсы, а затем отображать эти ресурсы для вас. Этот протокол запросов и ответов позволяет просматривать эта страница в вашем браузере.
В этой статье основное внимание уделяется одной фундаментальной части функционирования Интернета: HTTP.
Что такое HTTP?
HTTP означает протокол передачи гипертекста и используется для структурирования запросов и ответов через Интернет. HTTP требует передачи данных из одной точки в другую по сети.
Передача ресурсов происходит с использованием TCP (протокола управления передачей). При просмотре этой веб-страницы TCP управляет каналами между вашим браузером и сервером (в данном случае codecademy.com). TCP используется для управления многими типами интернет-соединений, в которых один компьютер или устройство хочет отправить что-то другому. HTTP — это командный язык, которому должны следовать устройства по обе стороны соединения для связи.
HTTP и TCP: как это работает
Когда вы вводите адрес, такой как www.codecademy.com, в свой браузер, вы даете ему команду открыть TCP-канал к серверу, который отвечает на этот URL-адрес (или унифицированный указатель ресурсов, о которых вы можете прочитать больше в Википедии). URL-адрес подобен вашему домашнему адресу или номеру телефона, потому что он описывает, как с вами связаться.
В этой ситуации ваш компьютер, который делает запрос, называется клиентом. URL-адрес, который вы запрашиваете, является адресом, принадлежащим серверу.
После установления TCP-соединения клиент отправляет HTTP-запрос GET на сервер, чтобы получить веб-страницу, которую он должен отображать. После того, как сервер отправил ответ, он закрывает TCP-соединение. Если вы снова открываете веб-сайт в своем браузере или если ваш браузер автоматически запрашивает что-то с сервера, открывается новое соединение, которое следует тому же процессу, который описан выше. Запросы GET — это один из видов HTTP-метода, который может вызвать клиент. Вы можете узнать больше о других распространенных ( ПОСТАВЬТЕ , ПОСТАВЬТЕ и УДАЛИТЕ ) в этой статье.
Давайте рассмотрим пример того, как запросы GET (наиболее распространенный тип запросов) используются, чтобы помочь вашему компьютеру (клиенту) получить доступ к ресурсам в Интернете.
Предположим, вы хотите ознакомиться с последними предложениями курсов на сайте http://codecademy. com. После того, как вы введете URL-адрес в свой браузер, ваш браузер извлечет часть http и распознает, что это имя используемого сетевого протокола. Затем он берет доменное имя из URL-адреса, в данном случае «codecademy.com», и запрашивает у сервера доменных имен в Интернете возврат адреса интернет-протокола (IP).
Теперь клиент знает IP-адрес получателя. Затем он открывает соединение с сервером по этому адресу, используя указанный протокол http . Он инициирует запрос GET на сервер, который содержит IP-адрес хоста и, возможно, полезные данные. Запрос GET содержит следующий текст:
GET / HTTP/1.1.
Хост: www.codecademy.com
Указывает тип запроса, путь на www.codecademy.com (в данном случае «/») и протокол «HTTP/1.1». HTTP/1.1 — это версия первого HTTP, который теперь называется HTTP/1.0. В HTTP/1.0 для каждого запроса ресурсов требуется отдельное подключение к серверу. HTTP/1.1 использует одно соединение более одного раза, поэтому дополнительный контент (например, изображения или таблицы стилей) извлекается даже после извлечения страницы. В результате запросы, использующие HTTP/1.1, имеют меньшую задержку, чем запросы, использующие HTTP/1.0.
Вторая строка запроса содержит адрес сервера "www.codecademy.com" . Также могут быть дополнительные строки в зависимости от того, какие данные ваш браузер выбирает для отправки.
Если сервер может найти запрошенный путь, сервер может ответить заголовком:
HTTP/1.1 200 OK
Content-Type: text/html
За этим заголовком следует запрошенный контент, который в данном случае является информацией, необходимой для отображения www.codecademy.com.
Первая строка заголовка, HTTP/1.1 200 OK , является подтверждением того, что сервер понимает протокол, с которым клиент хочет взаимодействовать ( HTTP/1.1 ), и код состояния HTTP, означающий, что ресурс был нашел на сервере. Третья строка, Content-Type: text/html , показывает тип содержимого, которое будет отправлено клиенту.
Если сервер не может найти путь, запрошенный клиентом, он ответит с заголовком:
HTTP/1. 1 404 NOT FOUND
В этом случае сервер определяет, что он понимает протокол HTTP, но код состояния 404 NOT FOUND означает, что конкретный запрошенный фрагмент контента не найден. Это может произойти, если содержимое было перемещено, или если вы неправильно ввели URL-адрес, или если страница была удалена. Подробнее о коде состояния 404, обычно называемом ошибкой 404, можно прочитать здесь.
Аналогия:
Понять, как работает HTTP, может быть сложно, потому что трудно понять, что на самом деле делает ваш браузер. (И, возможно, также потому, что мы объяснили это с помощью сокращений, которые могут быть для вас новыми.) Давайте повторим то, что мы узнали, используя аналогию, которая может быть вам более знакома.
Представьте, что Интернет — это город. Вы клиент, и ваш адрес определяет, где с вами можно связаться. Компании в городе, такие как Codecademy.com, обслуживают запросы, которые им отправляются. Другие дома заполнены другими клиентами, такими как вы, которые делают запросы и ожидают ответов от этих предприятий в городе. В этом городе также есть сумасшедшая быстрая почтовая служба, армия сотрудников службы доставки почты, которые могут путешествовать на поездах, движущихся со скоростью света.
Предположим, вы хотите прочитать утреннюю газету. Чтобы получить его, вы записываете то, что вам нужно, на языке, называемом HTTP, и просите своего местного агента по доставке почты получить это от конкретного предприятия. Сотрудник по доставке почты соглашается и почти мгновенно строит железнодорожную ветку (связь) между вашим домом и предприятием и едет в вагоне поезда с надписью «TCP» по указанному вами адресу предприятия.
Прибыв на предприятие, она спрашивает первого из нескольких свободных сотрудников, готовых выполнить просьбу. Сотрудник ищет запрошенную вами страницу газеты, но не может ее найти и сообщает об этом доставщику почты.
Доставщик почты возвращается на легком скоростном поезде, разрывая пути на обратном пути, и сообщает вам, что возникла проблема «404 Not Found». После проверки правописания того, что вы написали, вы понимаете, что ошиблись в названии газеты. Вы исправляете его и предоставляете исправленное название курьеру.
На этот раз доставщик почты может забрать его из компании. Теперь вы можете спокойно читать свою газету, пока не решите, что хотите прочитать следующую страницу, после чего вы должны сделать еще один запрос и передать его курьеру.
Что такое HTTPS?
Поскольку ваш HTTP-запрос может быть прочитан кем угодно при определенных сетевых соединениях, может быть нецелесообразно доставлять такую информацию, как ваша кредитная карта или пароль, с использованием этого протокола. К счастью, многие серверы поддерживают протокол HTTPS, сокращение от HTTP Secure, что позволяет шифровать данные, которые вы отправляете и получаете. Подробнее о HTTPS можно прочитать в Википедии.
Важно использовать HTTPS при передаче конфиденциальной или личной информации на веб-сайты и с них. Тем не менее, предприятия, обслуживающие серверы, должны его настроить. Для поддержки HTTPS компания должна подать заявку на получение сертификата в центре сертификации.
Узнать больше о Codecademy
Только Pro Путь навыков
Создание REST API с помощью Spring и Java
Подходит для начинающих,
20 Уроки
курс
Создайте профессиональный веб-сайт с помощью Velo от Wix
Подходит для начинающих,
13 Уроки
Хотите узнать, как быстро получить файл VA C? Вот 3 совета, как получить файл C в Интернете
Благодаря новой форме VA 20-10206 , Закону о свободе информации (FOIA) или Закону о конфиденциальности (форма запроса PA) теперь проще, чем когда-либо, получить копию ваш файл VA C быстро, и вы, наконец, можете запросить его онлайн по электронной почте.
Вместо того, чтобы ждать месяцы (или даже годы), чтобы получить C Файл в соответствии со старым процессом FOIA новый оптимизированный электронный процесс запроса VA FOIA занимает от начала до конца около 10-12 недель.
Хорошо, коллеги-ветераны, давайте поговорим о часто сбивающем с толку «Файле VA C» и о том, почему вы должны получить свой файл, независимо от того, на каком этапе процесса подачи заявления об инвалидности VA вы находитесь.
Содержание
Что такое файл VA C?
Ваше досье VA C содержит все рассмотренные подтверждающие доказательства и рейтинговые решения, принятые VA по каждому заявлению VA, которое вы подали.
Если вы думаете о большом картотечном шкафу с несколькими ящиками, отдельное исковое заявление VA, которое вы подали, будет одним ящиком в шкафу, тогда как ваш файл VA C ЯВЛЯЕТСЯ целым шкафом (все ящики и папки).
В то время как отдельная претензия может состоять из сотен страниц, C-файл ветерана обычно состоит из тысяч страниц и более.
Почему я должен запрашивать мой файл требований VA (C-файл)?
Вам следует получить копию вашего C-файла, потому что вы захотите ознакомиться с предыдущими доказательствами, рассмотренными VA, чтобы обеспечить точность предыдущих рейтинговых решений VA.
Если вам было отказано в заявлении VA, очень важно знать, какие доказательства были рассмотрены и приняты во внимание VA при отказе.
Внимательно ознакомьтесь с доказательствами, так как они помогут вам выработать лучшую стратегию подачи иска VA, если вы не согласны с обоснованием отказа VA.
Какие документы находятся в моем C File VA?
В вашем файле C есть много разных документов, включая, помимо прочего:
Форма VA 21-526EZ, Заявление на получение пособия по нетрудоспособности VA
DD 214, Сертификат о выпуске или выписке из Active Duty
Записи о лечении обслуживания
VA Medical Records
Частные медицинские записи
ОБЩЕСТВЕННА
Заявления в поддержку претензии
Письма VA Buddy Letters
Результаты экзамена C&P (включая результаты экзамена C&P частного подрядчика)
Письма о рейтингах
апелляции (предварительное уведомление о разногласиях, Обзоры более высокого уровня , Дополнительные претензии , Апелляции доски )
Внутренняя варенья
Как давно ?
В связи с текущим Журналом невыполненных требований VA , если вы запросите свой файл C в электронном виде (по электронной почте) в Центре приема доказательств Департамента по делам ветеранов , вы можете ожидать, что ваш файл VA C будет получен через 10-12 недель.
Могу ли я подать онлайн-запрос на файл VA C?
Да!
Форму VA Form 20-10206 (Форма запроса файла C) можно заполнить онлайн и отправить по электронной почте на номер [email protected]
После того, как вы заполните форму запроса файла C и отправите ее по электронной почте [email защищено], вам нужно войти в систему VA.gov, чтобы проверить статус вашего запроса FOIA.
Он появится в вашей учетной записи VA.gov как открытая заявка на «Запрос Закона о свободе информации / Закона о конфиденциальности» в течение 7–14 дней после подачи.
Вы можете продолжать следить за статусом, как и за любой другой претензией или апелляцией.
Как получить файл C онлайн (видеоурок)!
В этом видеоруководстве я покажу вам, как шаг за шагом выполнить новый процесс запроса VA FOIA, чтобы вы могли получить копию своего файла VA C онлайн (БЫСТРО!)
Если вам нужно помощь с заявлением об инвалидности VA, присоединитесь к программе VA Claims Insider Elite СЕГОДНЯ и начните подавать заявление об инвалидности VA на БЕСПЛАТНО.
Запрос VA FOIA на файл C – временные метки видео о том, как запросить файл VA C онлайн
⏩ 05:00 Почему вам следует получить файл C?
⏩ 08:10 Как заполнить форму запроса VA FOIA
⏩ 14:12 Почему стоит работать с VA Claims Insider?
⏩ 20:00 Раскрытие и объяснение метода SEM
⏩ 24:00 Мы помогаем ветеранам получить рейтинг VA, которого они заслуживают, за меньшее время. C File Online (трехэтапный процесс)
Онлайн запрос на получение VA C File Шаг #1: Загрузите форму VA 20-10206 и сохраните ее на своем компьютере
Вы можете заполнить форму онлайн или от руки.
При заполнении от руки распечатайте запрашиваемую информацию чернилами, аккуратно и разборчиво, и полностью заполните каждый применимый кружок, чтобы ускорить обработку формы.
Как быстро получить файл C Шаг № 2: Заполните форму, обращая особое внимание на разделы I, III, V и VI.
В Разделе III, Записи, которые вы ищете, щелкните переключатель «Файл требований (C-File)». если применимо
В Разделе V «Готовность платить сборы» введите номинальную сумму, например «50 долларов США».0003
Обязательно подпишите и поставьте дату Раздел VI.
Как получить файл C от VA в электронном виде Шаг № 3. Вы можете отправить заполненную форму по электронной почте: [email protected]
В течение 10-12 недель вы получите известие от VA с безопасной ссылкой для загрузки запрошенного файлы.
VA также отправит вам по почте CD-копию всего вашего C-файла VA.
Вы можете проверить статус своего запроса по Закону о свободе информации, как и любой другой претензии или апелляции, по телефону VA. gov.
Заслуживаете повышения рейтинга VA? Мы получили вашу шестерку!
В VA Claims Insider мы помогаем другим ветеранам отпраздновать ИЗМЕНЕНИЕ ЖИЗНИ , предоставив вам рейтинг инвалидности VA и компенсацию, которую вы заслуживаете по закону.
Мы принадлежим и руководим ветеранами! ДЛЯ Ветеранов, ОТ Ветеранов. Мы являемся крупнейшим сообществом ветеранов, помогающих ветеранам по всему миру™
10 000+ ветеранов-инвалидов, участвовавших в нашей программе Elite Membership с 2016 года и средний рейтинг инвалидности по программе VA увеличился более чем на 30%
Better Business Bureau (BBB) Accredited Business
4,8/5,0 Google Reviews рейтинг по более чем 1500 отзывам
Если вы готовы подать заявление об инвалидности VA рейтинг и вознаграждение, которые вы заработали за свою почетную службу нашей стране, просто нажмите кнопку ниже, чтобы начать наш БЕСПЛАТНЫЙ 3-этапный процесс приема. Через несколько минут вы получите известие от тренера-ветерана (VC)!
Стать инсайдером
Мы — ветеранов, помогающих Veterans Worldwide™, , и с 2016 года мы помогли более чем 10 000 ветеранам, как и вы, ПОВЫСИТЬ их рейтинг инвалидности VA!
Об авторе
Брайан Риз
Брайан Риз
Основатель и генеральный директор
Брайан Риз – эксперт по льготам для ветеранов, автор бестселлера №1 на Amazon Вы этого заслуживаете: подробное руководство по получению ветеранских пособий, которые вы заработали и основатель VA Claims Insider – «Наиболее надежное имя среди образовательных ресурсов для ветеранов».
Его недовольство 8-этапным процессом подачи заявления на получение инвалидности VA привело его к созданию «Инсайдер по заявлениям VA», , который предоставляет ветеранам вооруженных сил США советы, стратегии и извлеченные уроки для успешной подачи или повторной подачи заявки на выигрыш. Заявление о компенсации инвалидности VA.
Брайан - , а также генеральный директор из Военная инвалидность стала проще , которая является крупнейшей в мире бесплатной базой данных с возможностью поиска по всем вопросам, связанным с претензиями Министерства обороны США по инвалидности и заявлениям об инвалидности VA, и с момента своего основания в 2013 году обслуживала более 4 600 000 военнослужащих и ветеранов. Your VA Disability Claim» было загружено более 300 000 раз за последние три года, и это бесплатное руководство №1 для ветеранов по заявлениям об инвалидности VA.
бывший офицер ВВС 0027 с обширным опытом руководства сотнями отдельных лиц и многофункциональных групп в сложных международных условиях, включая боевой поход в Афганистан в 2011 году в поддержку операции "НЕПРЕРЫВНАЯ СВОБОДА".
Брайан является почетным выпускником Академии ВВС США , Колорадо-Спрингс, Колорадо, а также имеет степень магистра делового администрирования в Школе бизнеса Спирс Университета штата Оклахома, Стилуотер, Оклахома, где он был Национальным почетным стипендиатом (Top 1% класса аспирантуры).
No related posts.

Get запрос c: http — Отправка GET/POST-запроса средствами чистого C++

Сообщения HTTP — HTTP | MDN

Стартовая строка

Заголовки

Тело

Строка статуса (Status line)

Заголовки

Тело

какое количество считается правильным и как просканировать сайт

Сэкономьте время на изучении Serpstat

Рекомендуемые статьи

Как сделать запрос к API?

Ограничения

Авторизация

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

Примеры XML-запросов

Примеры JSON-запросов

Возможные коды ответов сервера

Отправить Get, Post, Удалить и поставить запрос с симуляцией почтальона

Отправить Get, Post, Удалить и поставить запрос с симуляцией почтальона

Отправить Get, Post, Удалить и поставить запрос с симуляцией почтальона

Интеллектуальная рекомендация

Как ссылаться на файлы * .jar, * .aar и .so в Android Studio

Модуль NGINX HTTP_RANDOM_INDEX_MODULE / Случайная домашняя страница (по умолчанию)

Python цифровой водяной знак (изображение и PDF документ)

BFMe x Longfeng Group объединяет усилия

Как войти в двойную часть учебника Guitar Pro

Вам также может понравиться

Несколько часто используемых макетов страниц

Сухие товары | Dubbo Community Developer Day Office Sharing

Проблема пространства имен нестандартного плагина Jquery

Intellij связан с местным хранилищем Maven

Java_linklist — это предварительная реализация

HTTP методы для создания RESTful сервисов

Взаимодействие браузера и сервера на примере GET и POST запросов. Обработка форм.

Содержание файла index.php:

HTTP-методов GET и POST

Что такое HTTP?

Методы HTTP

Метод GET

Метод POST

Сравнение GET и POST

Метод PUT

Метод HEAD

Метод DELETE

Метод PATCH

Метод OPTIONS

Метод CONNECT

Метод TRACE

COLOR PICKER

КОД ИГРЫ

Top Tutorials

Top1s Примеры HTML

C.4.

C.4.3 Операция C-GET

Примечание

C.4.3.1 Параметры сервиса C-GET

C.4.3.1.1 UID класса SOP

C.4.3.1.2 Приоритет

C.4.3.1.3 Идентификатор

Примечание

C.4.3.1.3.1 Структура идентификатора запроса

Примечание

C.4.3.1.3.2 Структура идентификатора ответа

C.

C.

C.4.3.1.6 Количество завершенных подопераций

C.4.3.1.7 Количество невыполненных подопераций

C.4.3.1.8 Количество подопераций предупреждения

Отправить HTTP-запрос — контакт (C)

curl — Как использовать

Имя

Краткий обзор

Описание

URL-адрес

Вывод

Протоколы

Индикатор выполнения

Опции

Файлы