| curl(1) | curl Manual | curl(1) |
نام (NAME)
curl - ابزاری برای انتقال داده از یا به سرور با استفاده از نشانیهای اینترنتی (URL)
خلاصه دستور (SYNOPSIS)
curl [options / URLs]
توضیحات (DESCRIPTION)
curl ابزاری برای انتقال داده از یا به یک سرور با استفاده از نشانیهای اینترنتی (URL) است. این ابزار از این پروتکلها پشتیبانی میکند: DICT، FILE، FTP، FTPS، GOPHER، GOPHERS، HTTP، HTTPS، IMAP، IMAPS، LDAP، LDAPS، MQTT، MQTTS، POP3، POP3S، RTSP، SCP، SFTP، SMB، SMBS، SMTP، SMTPS، TELNET، TFTP، WS و WSS.
curl برای تمامی ویژگیهای مربوط به انتقال، از libcurl نیرو میگیرد. برای جزئیات libcurl(3) را ببینید.
نشانی اینترنتی (URL)
نحو URL وابسته به پروتکل است. میتوانید توضیحات دقیق آن را در RFC 3986 بیابید.
اگر یک URL را بدون طرحواره ابتدایی "protocol://" مشخص کنید، curl حدس میزند چه پروتکلی مد نظر شماست. سپس بهطور پیشفرض روی HTTP قرار میگیرد، اما بر اساس پیشوندهای پرکاربرد نام میزبان موارد دیگر را در نظر میگیرد. برای مثال، برای نامهای میزبانی که با "ftp." شروع میشوند، curl فرض میکند شما FTP میخواهید.
شما میتوانید هر تعداد URL را در خط فرمان مشخص کنید. آنها بهصورت متوالی و به همان ترتیبی که مشخص شدهاند دریافت میشوند، مگر اینکه از --parallel استفاده کنید. میتوانید گزینههای خط فرمان و URLها را بهصورت ترکیبی و با هر ترتیبی در خط فرمان مشخص کنید.
curl هنگام انجام چندین انتقال تلاش میکند از اتصالات مجدداً استفاده کند، به طوری که دریافت فایلهای متعدد از یک سرور، اتصالات و دستتکانیهای راهاندازی چندگانه مصرف نکند. این کار سرعت را بهبود میبخشد. استفاده مجدد از اتصال تنها برای URLهایی که در یک فراخوانی خط فرمان مشخص شدهاند قابل انجام است و نمیتوان آن را بین اجراهای مجزای curl انجام داد.
curl هر آنچه را که در خط فرمان ارائه شود و گزینه خط فرمان یا آرگومان آن نباشد، یک URL فرض کرده و با آن به همین صورت رفتار میکند.
تطبیق الگو (GLOBBING)
شما میتوانید با نوشتن فهرستها درون آکولادها یا بازهها درون براکتها، چندین URL یا بخشهایی از URLها را مشخص کنید. ما این قابلیت را "globbing" (تطبیق الگو) مینامیم.
یک فهرست با سه نام مختلف را به این صورت مشخص کنید:
https://fun.example/{one,two,three}.jpg
sftp://{one,two,three}.example/README
دنبالههایی از سریهای حرفی-عددی را با استفاده از [] ایجاد کنید، مانند:
ftp://ftp.example.com/file[1-100].txt
با صفرهای پیشرو:
ftp://ftp.example.com/file[001-100].txt
با حروف الفبا:
ftp://ftp.example.com/file[a-z].txt
دنبالههای تو در تو پشتیبانی نمیشوند، اما میتوانید از چندین دنباله در کنار یکدیگر استفاده کنید:
https://example.com/archive[1996-1999]/vol[1-4]/part{a,b,c}.htmlمیتوانید یک گامشمار برای بازهها مشخص کنید تا هر Nاُمین عدد یا حرف را دریافت کنید:
https://example.com/file[1-100:10].txt https://example.com/file[a-z:2].txt
هنگام استفاده از دنبالههای [] یا {} در فراخوانی از اعلان خط فرمان، احتمالاً باید کل URL را درون علامت نقل قول دوگانه قرار دهید تا از تداخل پوسته با آن جلوگیری شود. این موضوع همچنین برای سایر نویسههایی که خاص تلقی میشوند، مانند '&'، '?' و '*' نیز صدق میکند.
بخشهای مجزای تطبیق الگو (globbing) را میتوان در گزینه --output ارجاع داد تا امکان استفاده مجدد از آنها در نام فایل مقصد فراهم شود.
از نسخه 8.21.0 در curl به بعد، بخشهای مجزای تطبیق الگو میتوانند نامگذاری شده و با نامهایشان مورد ارجاع قرار گیرند. این نام حرفی-عددی و حساس به بزرگی و کوچکی حروف، درون براکتهای زاویهدار پس از نویسه آغازین قرار میگیرد. مثالها:
https://fun.example/{<number>one,two,three}.jpg
ftp://ftp.example.com/file[<range>1-100].txt
تنظیم دو بار یک نام یکسان برای glob یک خطا است.
تطبیق الگو را با --globoff غیرفعال کنید.
متغیرها (VARIABLES)
curl از متغیرهای خط فرمان پشتیبانی میکند (اضافه شده در 8.3.0). متغیرها را با --variable name=content یا --variable name@file مقداردهی کنید (جایی که "file" در صورت تنظیم روی یک خط تیره منفرد (-) میتواند stdin باشد).
محتوای متغیر را میتوان با استفاده از "{{name}}" در پارامترهای گزینه گسترش داد، در صورتی که نام گزینه دارای پیشوند "--expand-" باشد. این کار محتوای متغیر "name" را درج میکند، یا در صورتی که این نام به عنوان متغیر وجود نداشته باشد، یک مقدار خالی درج میشود. برای درج دقیق "{{" در رشته، یک بکاسلش به عنوان پیشوند به آن اضافه کنید، مانند "\{{".
شما میتوانید با وارد کردن متغیرهای محیطی از طریق "--variable %name" به آنها دسترسی داشته باشید و آنها را گسترش دهید. این کار متغیری به نام "name" را وارد میکند، اما در صورتی که آن متغیر محیطی از قبل تنظیم نشده باشد، با یک خطا خارج میشود. برای ارائه یک مقدار پیشفرض در صورتی که از قبل تنظیم نشده باشد، از "--variable %name=content" یا "--variable %name@content" استفاده کنید.
مثال: دریافت متغیر محیطی USER و گسترش آن در URL؛ در صورتی که USER تنظیم نشده باشد با شکست مواجه میشود:
--variable '%USER'
--expand-url = "https://example.com/api/{{USER}}/method"
هنگام گسترش متغیرها، curl از مجموعهای از توابع پشتیبانی میکند که میتوانند استفاده از محتوای متغیر را راحتتر کنند. این ابزار میتواند فاصلههای خالی ابتدا و انتها را با "trim" حذف کند، محتوا را با "json" به صورت یک رشته با گیومههای JSON خروجی دهد، رشته را با "url" کدگذاری URL کند، با "b64" آن را کدگذاری base64 کند و با "64dec" آن را رمزگشایی base64 نماید. برای اعمال توابع روی گسترش متغیر، آنها را با علامت دونقطه (colon) در سمت راست متغیر اضافه کنید. محتوای متغیری که دارای بایتهای null باشد و هنگام گسترش کدگذاری نشود، باعث ایجاد خطا میشود.
مثال: دریافت محتوای فایلی به نام $HOME/.secret در متغیری به نام "fix". اطمینان حاصل کنید که محتوا هنگام ارسال به عنوان داده POST، پیراسته (trimmed) شده و percent-encoded باشد:
--variable %HOME
--expand-variable fix@{{HOME}}/.secret
--expand-data "{{fix:trim:url}}"
https://example.com
متغیرها و گسترشهای خط فرمان در 8.3.0 اضافه شدند.
خروجی (OUTPUT)
اگر دستور دیگری داده نشود، curl دادههای دریافتی را در stdout مینویسد. میتوان به آن دستور داد که در عوض با استفاده از گزینههای --output یا --remote-name آن دادهها را در یک فایل محلی ذخیره کند. اگر چندین URL برای انتقال در خط فرمان به curl داده شود، به طور مشابه به چندین گزینه برای مشخص کردن محل ذخیره آنها نیاز خواهد داشت.
curl محتوایی را که دریافت میکند یا به عنوان خروجی مینویسد، تجزیه یا به اصطلاح "درک" نمیکند. هیچگونه کدگذاری یا رمزگشایی انجام نمیدهد، مگر اینکه صریحاً با گزینههای اختصاصی خط فرمان از آن خواسته شود.
پروتکلها (PROTOCOLS)
curl از پروتکلهای متعددی پشتیبانی میکند، یا به بیان اصطلاحات URL: طرحها (schemes). ساخت (build) خاص شما ممکن است از همه آنها پشتیبانی نکند.
- DICT
- به شما امکان میدهد واژهها را با استفاده از فرهنگهای لغت آنلاین جستجو کنید.
- FILE
- خواندن یا نوشتن فایلهای محلی. curl از دسترسی به URLهای "file://" از راه دور پشتیبانی نمیکند، اما هنگام اجرا بر روی Microsoft Windows استفاده از رویکرد بومی UNC کار میکند. فقط مسیرهای مطلق.
- FTP(S)
- curl با ترفندها و اهرمهای کنترلی فراوان از File Transfer Protocol پشتیبانی میکند. با یا بدون استفاده از TLS.
- GOPHER(S)
- دریافت فایلها.
- HTTP(S)
- curl با گزینهها و گونههای متعددی از HTTP پشتیبانی میکند. بسته به گزینههای ساخت (build) و گزینههای صحیح خط فرمان، میتواند با نسخههای 0.9، 1.0، 1.1، 2 و 3 پروتکل HTTP ارتباط برقرار کند.
- IMAP(S)
- با استفاده از این پروتکل خواندن ایمیل، curl میتواند ایمیلها را برای شما دریافت کند. با یا بدون استفاده از TLS.
- LDAP(S)
- curl میتواند جستجوهای دایرکتوری را با یا بدون TLS برای شما انجام دهد.
- MQTT
- curl از پروتکل MQTT نسخه 3 پشتیبانی میکند. دانلود از طریق MQTT معادل اشتراک در یک تاپیک (subscribing to a topic) است، در حالی که بارگذاری/ارسال (uploading/posting) معادل انتشار در یک تاپیک (publishing on a topic) است. در حال حاضر MQTT بر روی TLS پشتیبانی نمیشود (هنوز).
- POP3(S)
- دانلود از یک سرور pop3 به معنای دریافت یک ایمیل است. با یا بدون استفاده از TLS.
- RTSP
- curl از دانلودهای RTSP 1.0 پشتیبانی میکند.
- SCP
- curl از انتقالهای scp در پروتکل SSH نسخه 2 پشتیبانی میکند.
- SFTP
- curl از SFTP (پیشنویس 5) انجامشده بر روی SSH نسخه 2 پشتیبانی میکند.
- SMB(S)
- curl از SMB نسخه 1 برای بارگذاری و بارگیری پشتیبانی میکند.
- SMTP(S)
- بارگذاری محتوا در یک سرور SMTP به معنای ارسال ایمیل است. با یا بدون TLS.
- TELNET
- واکشی یک URL مربوط به telnet یک نشست تعاملی را آغاز میکند که در آن آنچه را از stdin میخواند ارسال کرده و آنچه را سرور میفرستد در خروجی نمایش میدهد.
- TFTP
- curl میتواند بارگیریها و بارگذاریهای TFTP را انجام دهد.
- WS(S)
- WebSocket روی HTTP/1 انجام میشود. WSS دلالت بر این دارد که روی HTTPS کار میکند.
نشانگر پیشرفت (PROGRESS METER)
curl بهطور معمول در حین عملیات یک نشانگر پیشرفت را نمایش میدهد که نشاندهنده مقدار داده منتقلشده، سرعت انتقال، زمان تخمینی باقیمانده و موارد دیگر است. نشانگر پیشرفت، نرخ انتقال را بر حسب بایت بر ثانیه نمایش میدهد. پسوندهای بهکار رفته ("k" برای کیلو، "M" برای مگا، "G" برای گیگا، "T" برای ترا، "P" برای پتا و "E" برای اگزا) بر پایه 1024 هستند. برای مثال 1k برابر با 1024 بایت است. 1M برابر با 1048576 بایت است. به بیان دقیق، این امر واحدها را کیبیبایت و مبیبایت و غیره میسازد.
curl این دادهها را بهطور پیشفرض در ترمینال نمایش میدهد، بنابراین اگر curl را برای انجام عملیاتی فراخوانی کنید و در شرف نوشتن داده در ترمینال باشد، نشانگر پیشرفت را غیرفعال میکند چرا که در غیر این صورت با ترکیب شدن نشانگر پیشرفت و دادههای پاسخ، خروجی به هم میریزد.
اگر برای درخواستهای HTTP POST یا PUT خواستار یک نشانگر پیشرفت هستید، باید با استفاده از تغییر مسیر شل (>)، --output یا موارد مشابه، خروجی پاسخ را به یک فایل هدایت کنید.
این موضوع برای بارگذاری FTP صدق نمیکند، زیرا آن عملیات هیچ داده پاسخی را به ترمینال ارسال نمیکند.
اگر به جای نشانگر معمولی، یک نوار پیشرفت را ترجیح میدهید، --progress-bar به کارتان میآید. همچنین میتوانید با گزینه --silent نشانگر پیشرفت را بهطور کامل غیرفعال کنید.
نسخه (VERSION)
این صفحه راهنما curl 8.22.0 را شرح میدهد. اگر از نسخه جدیدتری استفاده میکنید، احتمال دارد که این صفحه راهنما آن را بهطور کامل مستند نکرده باشد. اگر از نسخه قدیمیتر استفاده میکنید، این سند تلاش میکند اطلاعات مربوط به نسخهای را که تغییرات را معرفی کرده است شامل شود.
همواره میتوانید با اجرای دستور زیر مطلع شوید که آخرین نسخه curl کدام است:
curl https://curl.se/info
نسخه آنلاین این صفحه راهنما همواره آخرین نگارش را نشان میدهد: https://curl.se/docs/manpage.html
گزینهها (OPTIONS)
گزینهها با یک یا دو خط تیره آغاز میشوند. بسیاری از گزینهها نیازمند یک مقدار اضافی در کنار خود هستند. اگر متن ارائهشده با یک خط تیره آغاز نشود، فرض میشود که یک URL است و با آن بهعنوان یک URL برخورد میشود.
فرم کوتاه "single-dash" گزینهها، برای مثال -d، میتواند با یا بدون فاصله بین آن و مقدارش استفاده شود، اگرچه وجود یک فاصله بهعنوان جداکننده توصیه میشود. فرم بلند دو خط تیره، برای مثال --data، به یک فاصله بین خود و مقدارش نیاز دارد.
گزینههای نسخه کوتاه که به مقادیر اضافی نیاز ندارند، میتوانند بلافاصله در کنار یکدیگر استفاده شوند؛ مانند اینکه میتوانید تمام گزینههای -O، -L و -v را یکجا بهصورت -OLv مشخص کنید.
بهطور کلی، تمام گزینههای بولی با --option فعال شده و مجدداً با --no-option غیرفعال میشوند. یعنی شما از همان نام گزینه استفاده میکنید اما پیشوند "no-" را به ابتدای آن میافزایید. در این فهرست ما بیشتر نسخه --option آنها را نشان میدهیم.
هنگامی که از --next استفاده میشود، وضعیت تجزیهگر بازنشانی شده و بهجز گزینههایی که سراسری هستند، دوباره با یک وضعیت تمیز از گزینهها شروع میکنید. گزینههای سراسری حتی پس از --next نیز مقدار و معنای خود را حفظ میکنند.
اگر نام گزینه طولانی به علامت مساوی ("=") ختم شود، آرگومان همان متنی است که در سمت راست آن قرار دارد. (افزودهشده در 8.16.0)
نخستین آرگومانی که دقیقاً دو خط تیره ("--") باشد، پایان گزینهها را مشخص میکند؛ هر آرگومانی پس از پایان گزینهها بهعنوان یک آرگومان URL تفسیر میشود، حتی اگر با یک خط تیره شروع شود.
curl بررسی اندکی بر روی محتوای آرگومانهای خط فرمان انجام میدهد یا اصلاً اعتبارسنجی نمیکند. ارسال "بایتهای خلاقانه" مانند خطوط جدید ممکن است نتایج غیرمنتظرهای در پی داشته باشد.
گزینههای زیر سراسری هستند: --fail-early، --libcurl، --parallel-immediate، --parallel-max-host، --parallel-max، --parallel، --progress-bar، --rate، --show-error، --stderr، --styled-output، --trace-ascii، --trace-config، --trace-ids، --trace-time، --trace و --verbose.
همه گزینهها (ALL OPTIONS)
- --abstract-unix-socket <path>
- (HTTP) به جای
استفاده از
شبکه، از
طریق یک
سوکت
انتزاعی
دامنه
یونیکس (abstract Unix domain
socket) به سرور
متصل شوید.
نکته: netstat مسیر
یک سوکت
انتزاعی را
با پیشوند
"@" نشان
میدهد، با
این حال
آرگومان <path>
نباید این
نویسه
ابتدایی را
داشته باشد.
اگر --abstract-unix-socket چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --abstract-unix-socket socketpath https://example.com
همچنین ببینید --unix-socket.
- --alt-svc <filename>
- (HTTPS) تجزیهگر
alt-svc را فعال
میکند. اگر
نام فایل به
یک فایل کَش
موجود alt-svc
اشاره کند،
از آن
استفاده
میشود. پس
از یک
انتقال
کاملشده،
در صورت
تغییر، کَش
دوباره در
همان نام
فایل ذخیره
میشود.
یک نام فایل "" (با طول صفر) مشخص کنید تا از بارگذاری/ذخیرهسازی جلوگیری شود و curl کَش را در حافظه مدیریت کند.
ممکن است بخواهید umask خود را محدود کنید تا از دسترسی سایر کاربران در همان سیستم به فایل ایجادشده جلوگیری شود.
اگر این گزینه چندین بار استفاده شود، curl محتویات را از همهٔ فایلها بارگذاری میکند اما آخرین مورد برای ذخیرهسازی استفاده میشود.
--alt-svc میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --alt-svc svc.txt https://example.com
همچنین --resolve و --connect-to را ببینید.
- --anyauth
- (HTTP) روش احراز
هویت را
بهطور
خودکار
تشخیص داده
و از
امنترین
روشی که
سایت مقصد
ادعا
میکند
پشتیبانی
میکند،
استفاده
میکند. این
کار با
انجام یک
درخواست
اولیه و
بررسی response-headers
انجام
میشود،
بنابراین
ممکن است یک
رفتوبرگشت
اضافی شبکه
ایجاد کند.
این گزینه
بهجای
تنظیم یک
روش احراز
هویت خاص
استفاده
میشود،
کاری که
میتوانید
با --basic، --digest،
--ntlm و --negotiate
انجام دهید.
در صورتی که بارگذاری را از stdin انجام میدهید، استفاده از --anyauth توصیه نمیشود، زیرا ممکن است نیاز باشد دادهها دو بار ارسال شوند و سپس کلاینت باید بتواند به عقب برگردد (rewind کند). اگر این نیاز هنگام بارگذاری از stdin پیش بیاید، عملیات بارگذاری با شکست مواجه میشود.
همراه با --user استفاده میشود.
مثال:
curl --anyauth --user me:pwd https://example.com
همچنین --proxy-anyauth، --basic و --digest را ببینید.
- -a, --append
- (FTP SFTP) هنگام
استفاده در
یک
بارگذاری،
این گزینه
باعث
میشود curl
بهجای
بازنویسی
فایل مقصد،
به انتهای
آن اضافه
کند. اگر
فایل
دوردست
وجود
نداشته
باشد،
ایجاد
میشود.
توجه داشته
باشید که
این پرچم
توسط برخی
از سرورهای
SFTP (از جمله OpenSSH)
نادیده
گرفته
میشود.
ارائهٔ چندینبارهٔ --append تأثیر اضافهای ندارد. دوباره با --no-append آن را غیرفعال کنید.
مثال:
curl --upload-file local --append ftp://example.com/
همچنین --range و --continue-at را ببینید.
- --aws-sigv4 <provider1[:prvdr2[:reg[:srv]]]>
- (HTTP) استفاده
از احراز
هویت با
امضای AWS V4 در
انتقال.
آرگومان provider رشتهای است که هنگام ایجاد سرآیندهای احراز هویت خروجی، توسط الگوریتم استفاده میشود.
آرگومان region رشتهای است که در صورت حذف نام منطقه از endpoint، به یک منطقهٔ جغرافیایی از یک مجموعه منابع (region-code) اشاره میکند.
آرگومان service رشتهای است که در صورت حذف نام سرویس از endpoint، به یک تابع ارائهشده توسط ابر (service-code) اشاره میکند.
اگر --aws-sigv4 چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --aws-sigv4 "aws:amz:us-east-2:es" --user "key:secret" https://example.com
در 7.75.0 اضافه شد. همچنین --basic و --user را ببینید.
- --basic
- (HTTP) از احراز
هویت HTTP Basic با
میزبان
دوردست
استفاده
میکند. این
روش پیشفرض
است و این
گزینه
معمولاً
بیفایده
است، مگر
اینکه از آن
برای
جایگزینی
یک گزینهٔ
از پیش
تنظیمشده
که روش
احراز هویت
متفاوتی
تعیین
میکند
(مانند --ntlm،
--digest یا --negotiate)
استفاده
کنید.
همراه با --user استفاده میشود.
ارائهٔ چندینبارهٔ --basic تأثیر اضافهای ندارد. دوباره با --no-basic آن را غیرفعال کنید.
مثال:
curl -u name:password --basic https://example.com
همچنین --proxy-basic را ببینید.
- --ca-native
- (TLS) از مخزن
بومی CA
سیستمعامل
برای
اعتبارسنجی
گواهی
استفاده
میکند.
این گزینه مستقل از سایر مکانهای گواهی CA تعیینشده در زمان اجرا یا زمان ساخت است. آن مکانها علاوه بر مخزن بومی CA جستجو میشوند.
این گزینه با OpenSSL و شاخههای آن (BoringSSL، LibreSSL و غیره) در Windows (اضافهشده در 7.71.0) و در سیستمعامل Apple در صورتی که libcurl با فعال بودن Apple SecTrust ساخته شده باشد، کار میکند. (اضافهشده در 8.17.0)
این گزینه با wolfSSL در Windows، Linux (توزیعهای Debian، Ubuntu، Gentoo، Fedora، RHEL)، macOS، Android و iOS کار میکند. (اضافهشده در 8.3.0)
این گزینه با GnuTLS کار میکند (اضافهشده در 8.5.0) و همچنین در صورتی که libcurl با آن ساخته شده باشد، از Apple SecTrust استفاده میکند. (اضافهشده در 8.17.0)
این گزینه با Rustls در Windows، macOS، Android و iOS کار میکند. در Linux این گزینه معادل استفاده از بسته گواهی CA متعلق به Mozilla است. هنگام استفاده با Rustls، تنها به مخزن بومی CA مراجعه میشود، نه به مکانهای دیگرِ تعیینشده در زمان اجرا یا زمان ساخت. (اضافهشده در 8.13.0)
این گزینه در حال حاضر هیچ تاثیری برای Schannel ندارد. این کتابخانه بومی TLS از طرف Microsoft است که بهطور پیشفرض از مخزن بومی CA برای اعتبارسنجی استفاده میکند، مگر اینکه با تنظیم مکان گواهی CA بازنویسی شده باشد.
ارائه چندباره --ca-native تاثیر مضاعفی ندارد. آن را مجدداً با --no-ca-native غیرفعال کنید.
مثال:
curl --ca-native https://example.com
اضافهشده در 8.2.0. همچنین ببینید --cacert، --capath، --dump-ca-embed، --insecure و --proxy-ca-native.
- --cacert <file>
- (TLS) از پرونده
گواهی
مشخصشده
برای
اعتبارسنجی
طرف مقابل (peer)
استفاده
میکند. این
پرونده
ممکن است
حاوی چندین
گواهی CA
باشد.
گواهی(ها)
باید در
قالب PEM
باشند.
بهطور
معمول curl
برای
استفاده از
یک پرونده
پیشفرض
برای این
منظور
ساخته
میشود،
بنابراین
این گزینه
معمولاً
برای تغییر
آن پرونده
پیشفرض
استفاده
میشود.
اگر متغیر محیطی با نام 'CURL_CA_BUNDLE' تنظیم شده باشد و بکاند TLS ابزار Schannel نباشد، curl آن را شناسایی کرده و از مسیر ارائهشده بهعنوان مسیر بسته گواهی CA استفاده میکند. این گزینه آن متغیر را بازنویسی میکند.
(Windows) ابزار curl بهطور خودکار به دنبال پرونده گواهیهای CA به نام 'curl-ca-bundle.crt' میگردد؛ یا در همان دایرکتوری curl.exe، یا در دایرکتوری کاری فعلی (Current Working Directory)، یا در هر پوشهای در امتداد PATH شما.
در curl 8.11.0 یک گزینه در زمان ساخت (build-time) برای غیرفعال کردن این رفتار جستجو، و گزینه دیگری برای محدود کردن جستجو به دایرکتوری برنامه اضافه شد.
(Schannel) این گزینه برای Schannel در Windows 7 یا بالاتر پشتیبانی میشود (اضافهشده در 7.60.0). این گزینه برای سازگاری عقبروی با سایر موتورهای SSL پشتیبانی میشود؛ در عوض توصیه میشود از مخزن گواهیهای ریشه Windows (پیشفرض برای Schannel) استفاده کنید.
اگر --cacert چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --cacert CA-file.txt https://example.com
همچنین ببینید --capath، --dump-ca-embed و --insecure.
- --capath <dir>
- (TLS) از پوشه
(دایرکتوری)
گواهی
مشخصشده
برای
اعتبارسنجی
طرف مقابل
استفاده
میکند. اگر
curl با OpenSSL ساخته
شده باشد،
میتوان با
جدا کردن
مسیرها
توسط
جداکننده
مخصوص
پلتفرم
مربوطه،
چندین مسیر
را ارائه
داد (مثلاً
"path1:path2:path3" در
پلتفرمهای
شبهیونیکس
برای "path1;path2;path3"
در Windows).
گواهیها باید در قالب PEM باشند، و در صورتی که curl با OpenSSL ساخته شده باشد، دایرکتوری باید با استفاده از ابزار کمکی c_rehash ارائهشده همراه با OpenSSL پردازش شده باشد. اگر پرونده --cacert حاوی تعداد زیادی گواهی CA باشد، استفاده از --capath میتواند به curl مبتنی بر OpenSSL امکان دهد تا اتصالات SSL را بسیار کارآمدتر از حالت استفاده از --cacert برقرار کند.
اگر این گزینه تنظیم شود، مقدار پیشفرض capath نادیده گرفته میشود.
اگر --capath چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --capath /local/directory https://example.com
همچنین ببینید --cacert، --dump-ca-embed و --insecure.
- -E, --cert <certificate[:password]>
- (TLS) هنگام
دریافت
پرونده با
HTTPS، FTPS یا
پروتکل
دیگری
مبتنی بر SSL،
از پرونده
گواهی
کلاینت
مشخصشده
استفاده
میکند.
گواهی باید
در قالب PEM
باشد. اگر
گذرواژه
اختیاری
مشخص نشده
باشد، در
ترمینال
درخواست
میشود.
توجه داشته
باشید که
این گزینه
فرض میکند
پرونده
گواهی،
ترکیبی از
پیوستهشدن
کلید خصوصی
و گواهی
کلاینت است.
برای مشخص
کردن مستقل
آنها، --cert و
--key را
ببینید.
در بخش <certificate> این آرگومان، باید نویسه ":" را بهصورت "\:" گریز دهید (اسکیپ کنید) تا بهعنوان جداکننده گذرواژه شناخته نشود. بهطور مشابه، باید نویسه گیومه دوگانه را بهصورت \" گریز دهید تا بهعنوان نویسه گریز شناخته نشود.
اگر curl با OpenSSL ساخته شده باشد و موتور pkcs11 یا ارائهدهنده pkcs11 در دسترس باشد، میتوان از یک نشانی PKCS#11 URI (استاندارد RFC 7512) برای مشخص کردن گواهی موجود در یک دستگاه PKCS#11 استفاده کرد. رشتهای که با "pkcs11:" شروع شود، بهعنوان یک PKCS#11 URI تفسیر میشود. اگر یک PKCS#11 URI ارائه شود، در صورتی که گزینهای مشخص نشده باشد، گزینه --engine روی "pkcs11" تنظیم میشود و گزینه --cert-type نیز در صورتی که مشخص نشده باشد، بر روی "ENG" یا "PROV" قرار میگیرد (بسته به نسخه OpenSSL).
اگر curl با GnuTLS ساخته شده باشد، میتوان از یک PKCS#11 URI برای مشخص کردن گواهی موجود در یک دستگاه PKCS#11 استفاده کرد. رشتهای که با "pkcs11:" شروع شود، بهعنوان یک PKCS#11 URI تفسیر میشود.
(Schannel) گواهیهای کلاینت باید با عبارت مسیر به یک مخزن گواهی مشخص شوند. (بارگذاری PFX پشتیبانی نمیشود؛ ابتدا میتوانید آن را به یک مخزن وارد کنید). میتوانید از "<store location>\<store name>\<thumbprint>" برای اشاره به یک گواهی در مخزن گواهیهای سیستم استفاده کنید، برای مثال: "CurrentUser\MY\934a7ac6f8a5d579285a74fa61e19f23ddfe8d7a". اثر انگشت (Thumbprint) معمولاً یک رشته هگزادسیمال SHA-1 است که میتوانید آن را در جزئیات گواهی مشاهده کنید. مکانهای مخزن زیر پشتیبانی میشوند: CurrentUser، LocalMachine، CurrentService، Services، CurrentUserGroupPolicy، LocalMachineGroupPolicy و LocalMachineEnterprise.
اگر --cert چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --cert certfile --key keyfile https://example.com
همچنین ببینید --cert-type، --key و --key-type.
- --cert-status
- (TLS) وضعیت
گواهی سرور
را با
استفاده از
افزونهٔ TLS
به نام Certificate Status Request
(معروف به OCSP stapling)
بررسی
میکند.
اگر این گزینه فعال باشد و سرور پاسخی نامعتبر (مثلاً منقضیشده) ارسال کند، یا اگر پاسخ نشان دهد که گواهی سرور باطل شده است، یا هیچ پاسخی دریافت نشود، اعتبارسنجی با شکست مواجه میشود.
این پشتیبانی در حال حاضر تنها در بکاندهای OpenSSL و GnuTLS پیادهسازی شده است.
ارائهٔ چندبارهٔ --cert-status هیچ اثر اضافهای ندارد. با --no-cert-status دوباره آن را غیرفعال کنید.
مثال:
curl --cert-status https://example.com
همچنین ببینید --pinnedpubkey.
- --cert-type <type>
- (TLS) نوع گواهی
کلاینت
ارائهشده
را مشخص
میکند.
انواع PEM، DER،
ENG، PROV و P12 انواع
شناختهشده
هستند.
نوع پیشفرض به بکاند TLS بستگی دارد و معمولاً PEM است. برای Schannel این نوع P12 است. اگر --cert یک pkcs11: URI باشد، نوع پیشفرض ENG یا PROV خواهد بود (بسته به نسخهٔ OpenSSL).
اگر --cert-type چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --cert-type PEM --cert file https://example.com
همچنین ببینید --cert، --key و --key-type.
- --ciphers <list>
- (TLS) مشخص
میکند در
صورتی که
اتصال بر سر
TLS 1.2 (یا 1.1، 1.0)
مذاکره
کند، از
کدام
مجموعههای
رمز (cipher suites) در
ارتباط
استفاده
شود. فهرست
مجموعههای
رمز باید
رمزهای
معتبری را
مشخص کند.
جزئیات
مجموعههای
رمز را در
این نشانی
اینترنتی
بخوانید:
https://curl.se/docs/ssl-ciphers.html
اگر --ciphers چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 https://example.com
همچنین ببینید --tls13-ciphers، --proxy-ciphers و --curves.
- --compressed
- (HTTP) درخواست
پاسخی
فشردهشده
با استفاده
از یکی از
الگوریتمهای
مورد
پشتیبانی curl
میدهد و
محتوا را
بهطور
خودکار از
حالت فشرده
خارج
میکند.
سرآیندهای پاسخ هنگام ذخیره شدن تغییر داده نمیشوند؛ بنابراین اگر بعداً دوباره بهطور جداگانه «تفسیر» شوند، ممکن است اینگونه به نظر برسد که میگویند محتوا (همچنان) فشرده است؛ در حالی که در واقع قبلاً از حالت فشرده خارج شده است.
اگر از این گزینه استفاده شود و سرور یک کدگذاری پشتیبانینشده ارسال کند، curl خطا گزارش میدهد. این یک درخواست است، نه یک دستور؛ سرور ممکن است دادهها را بهصورت فشرده تحویل دهد یا ندهد.
هشدار: هنگام خارجسازی دادهها از حالت فشرده، حتی انتقالهای بسیار کوچک نیز ممکن است باز شده و حجم عظیمی از بایتها ایجاد کنند. شاید بخواهید استفاده از این گزینه را تنها به وبگاههای شناختهشده و قابل اعتماد با استفاده از پروتکلهای امن محدود کنید، شاید در ترکیب با --max-filesize.
ارائهٔ چندبارهٔ --compressed هیچ اثر اضافهای ندارد. با --no-compressed دوباره آن را غیرفعال کنید.
مثال:
curl --compressed https://example.com
همچنین ببینید --compressed-ssh.
- --compressed-ssh
- (SCP SFTP)
فشردهسازی
SSH را فعال
میکند. این
یک درخواست
است، نه یک
دستور؛
سرور ممکن
است آن را
انجام دهد
یا ندهد.
این امکان
میدهد
دادهها
بهصورت
فشرده روی
خط ارتباطی
ارسال شوند
و در مقصد
بهطور
خودکار از
حالت فشرده
خارج گردند
تا در پهنای
باند
صرفهجویی
شود.
ارائهٔ چندبارهٔ --compressed-ssh هیچ اثر اضافهای ندارد. با --no-compressed-ssh دوباره آن را غیرفعال کنید.
مثال:
curl --compressed-ssh sftp://example.com/
همچنین ببینید --compressed.
- -K, --config <file>
- یک پرونده
متنی را
برای
خواندن
آرگومانهای
curl از آن مشخص
کنید.
آرگومانهای
خط فرمان
موجود در
این پرونده
متنی
بهگونهای
استفاده
میشوند که
گویی در خود
خط فرمان
ارائه
شدهاند.
گزینهها و پارامترهای آنها باید در همان خط در پرونده مشخص شوند و با فاصله خالی (whitespace)، دو نقطه یا علامت مساوی از یکدیگر جدا شوند. نام گزینههای طولانی را میتوان به صورت اختیاری در پرونده پیکربندی بدون دو خط تیره ابتدایی ذکر کرد و در این صورت، نویسههای دو نقطه یا مساوی میتوانند به عنوان جداکننده استفاده شوند. اگر گزینه با یک یا دو خط تیره مشخص شود، نباید هیچ نویسه دو نقطه یا مساوی بین گزینه و پارامتر آن وجود داشته باشد.
اگر پارامتر حاوی فاصله خالی باشد یا با دو نقطه (:) یا علامت مساوی (=) آغاز شود، باید درون علامت نقلقول دوتایی ("like this") محصور شود. در داخل نقلقولهای دوتایی، دنبالههای گریز زیر در دسترس هستند: \\, \", \t, \n, \r و \v. وجود یک بکاسلش پیش از هر حرف دیگری نادیده گرفته میشود.
اگر نخستین ستون غیرخالی یک خط پیکربندی نویسه '#' باشد، آن خط به عنوان توضیح (کامنت) در نظر گرفته میشود.
در پرونده پیکربندی، در هر خط فیزیکی تنها یک گزینه بنویسید. اندازه یک خط نباید بیشتر از ۱۰ مگابایت باشد (از نسخه 8.2.0 به بعد).
نام پرونده را برای --config به صورت علامت منفی "-" مشخص کنید تا curl پرونده را از stdin بخواند.
توجه داشته باشید که برای امکان تعیین یک URL در پرونده پیکربندی، باید آن را با استفاده از گزینه --url مشخص کنید، نه با نوشتن URL در یک خط جداگانه به تنهایی. میتواند شبیه به این باشد:
url = "https://curl.se/docs/" # --- Example file --- # this is a comment url = "example.com" output = "curlhere.html" user-agent = "superagent/1.0" # and fetch another URL too url = "example.com/docs/manpage.html" -O referer = "http://nowhereatall.example.com/" # --- End of example file ---
هنگامی که curl فراخوانی میشود، (مگر اینکه از --disable استفاده شده باشد) وجود یک پرونده پیکربندی پیشفرض را بررسی کرده و در صورت پیدا شدن، حتی زمانی که از --config استفاده شده باشد، از آن استفاده میکند. پرونده پیکربندی پیشفرض به این ترتیب در مکانهای زیر جستجو میشود:
1) "$CURL_HOME/.curlrc"
2) "$XDG_CONFIG_HOME/curlrc" (افزوده شده در 7.73.0)
3) "$HOME/.curlrc"
4) ویندوز: "%USERPROFILE%\.curlrc"
5) ویندوز: "%APPDATA%\.curlrc"
6) ویندوز: "%USERPROFILE%\Application Data\.curlrc"
7) غیر ویندوز: استفاده از getpwuid برای یافتن دایرکتوری خانگی
8) در ویندوز، اگر هیچ پرونده .curlrc در ترتیبی که در بالا توصیف شد پیدا نشود، وجود آن را در همان پوشهای که فایل اجرایی curl قرار دارد بررسی میکند.
در ویندوز برای هر مکان، دو نام پرونده بررسی میشود: .curlrc و _curlrc، که اولویت با اولی است. نسخههای قدیمیتر در ویندوز تنها _curlrc را بررسی میکردند.
گزینه --config میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --config file.txt https://example.com
همچنین ببینید: --disable.
- --connect-timeout <seconds>
- حداکثر
زمان بر حسب
ثانیه که به
برقراری
اتصال curl
اجازه
میدهید.
این گزینه
فقط مرحله
اتصال را
محدود
میکند،
بنابراین
اگر curl در
بازه زمانی
دادهشده
متصل شود
ادامه
میدهد - در
غیر این
صورت خارج
میشود.
این گزینه مقادیر اعشاری را میپذیرد. مقدار اعشاری باید با استفاده از نقطه (.) به عنوان جداکننده اعشار ارائه شود - نه نسخه محلی، حتی اگر از جداکننده دیگری استفاده کند.
مرحله اتصال زمانی کامل در نظر گرفته میشود که جستجوی DNS و دستدهیهای درخواستی TCP، TLS یا QUIC انجام شده باشند.
اگر --connect-timeout چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثالها:
curl --connect-timeout 20 https://example.com curl --connect-timeout 3.14 https://example.com
همچنین ببینید: --max-time.
- --connect-to <HOST1:PORT1:HOST2:PORT2>
- برای
درخواستی
که برای جفت
"HOST1:PORT1" در نظر
گرفته شده
است، در عوض
به "HOST2:PORT2" متصل
شوید. این
گزینه تنها
برای
برقراری
اتصال شبکه
استفاده
میشود. این
گزینه بر
نام
میزبان/شماره
درگاه مورد
استفاده
برای TLS/SSL
(مانند SNI،
اعتبارسنجی
گواهی) یا
برای
پروتکلهای
کاربردی
هیچ تأثیری
نمیگذارد.
مقادیر "HOST1" و "PORT1" میتوانند رشتههای خالی باشند، به این معنی که هر میزبان یا هر شماره درگاهی پذیرفته است. همچنین "HOST2" و "PORT2" میتوانند رشتههای خالی باشند، به این معنا که از نام میزبان و شماره درگاه اصلی درخواست استفاده شود.
نام میزبانی که برای این گزینه مشخص میشود به صورت یک رشته مقایسه میشود، بنابراین باید با نام استفادهشده در URL درخواست مطابقت داشته باشد. این مقدار میتواند عددی مانند "127.0.0.1" یا نام کامل میزبان مانند "example.org" باشد.
مثال: هدایت اتصالها از نام میزبان example.com به 127.0.0.1 بدون در نظر گرفتن شماره درگاه:
curl --connect-to example.com::127.0.0.1: https://example.com
مثال: هدایت اتصالها از همه نامهای میزبان به 127.0.0.1 بدون در نظر گرفتن شماره درگاه:
curl --connect-to ::127.0.0.1: http://example.com
گزینه --connect-to میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --connect-to example.com:443:example.net:8443 https://example.com
همچنین --resolve و --header را ببینید.
- -C, --continue-at <offset>
- ادامه
انتقال
قبلی از
آفست بایتی
دادهشده.
آفست
دادهشده
تعداد دقیق
بایتهایی
است که پیش
از انتقال
به مقصد، با
شمارش از
ابتدای
پرونده
مبدأ
نادیده
گرفته
میشوند. در
صورت
استفاده در
بارگذاریها،
دستور SIZE
سرور FTP توسط curl
استفاده
نمیشود.
از "-C -" استفاده کنید تا به curl دستور دهید محل و نحوه ادامه انتقال را به طور خودکار پیدا کند. سپس برای پی بردن به آن، از پروندههای ورودی/خروجی مشخصشده استفاده میکند.
هنگام استفاده از این گزینه برای بارگذاریهای HTTP با استفاده از POST یا PUT، عملکرد آن تضمین نمیشود. پروتکل HTTP هیچ روش استاندارد و همکنشپذیری برای ادامه بارگذاری ندارد و curl برای این منظور از مجموعهای از سرآیندها استفاده میکند که زمانی کارکرد آنها برای برخی سرورها به اثبات رسیده است و برای کسانی که آن را مفید میدانند باقی ماندهاند.
این گزینه خط فرمان با --range ناسازگار (مانعةالجمع) است: شما فقط میتوانید از یکی از آنها برای یک انتقال استفاده کنید.
گزینههای --no-clobber و --remove-on-error نمیتوانند همراه با --continue-at استفاده شوند.
اگر --continue-at چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
curl -C - https://example.com curl -C 400 https://example.com
همچنین --range را ببینید.
- -b, --cookie <data|filename>
- (HTTP) این گزینه
دو عملکرد
تا حدی مجزا
برای ارسال
کوکی دارد.
یا: دادههای دقیقی را که باید در سرآیند Cookie به سرور HTTP ارسال شوند ارسال کنید. فرض بر این است که این دادهها قبلاً از سرور در یک خط "Set-Cookie:" دریافت شدهاند. دادهها باید در قالب "NAME1=VALUE1; NAME2=VALUE2" باشند. هنگامی که مجموعهای از کوکیهای مشخص به آن داده میشود، curl سرآیند کوکی خود را به صراحت با این محتوا در تمام درخواستهای خروجی پر میکند. اگر چندین درخواست به دلیل احراز هویت، دنبال کردن تغییر مسیرها یا موارد مشابه انجام شود، این سرآیند کوکی به همه آنها ارسال میگردد.
یا: اگر از نماد "=" در آرگومان استفاده نشود، در عوض به عنوان نام پروندهای برای خواندن کوکیهای از قبل ذخیرهشده در نظر گرفته میشود. این گزینه همچنین موتور کوکی را فعال میکند که باعث میشود curl کوکیهای ورودی را ثبت کند، که اگر از آن در ترکیب با گزینه --location استفاده کنید یا چندین انتقال URL را در همان فراخوانی انجام دهید، میتواند مفید باشد.
اگر نام پرونده یک خط تیره منفرد ("-") باشد، curl محتویات را از stdin میخواند. اگر نام پرونده یک رشته خالی ("") باشد و تنها ورودی کوکی باشد، curl موتور کوکی را بدون هیچ کوکیای فعال میکند.
قالب پروندهای که کوکیها از آن خوانده میشوند باید سرآیندهای متنی ساده HTTP (سبک Set-Cookie) یا قالب پرونده کوکی Netscape/Mozilla باشد. ما استفاده از سبک سرآیند HTTP را توصیه نمیکنیم.
پرونده مشخصشده با --cookie تنها به عنوان ورودی استفاده میشود. هیچ کوکیای در آن پرونده نوشته نمیشود. برای ذخیره کوکیها، از گزینه --cookie-jar استفاده کنید.
اگر کوکیها را از یک پرونده متنی ساده سرآیندهای HTTP میخوانید، مطمئن شوید که هر خط "Set-Cookie" یک صفت "Domain" را مشخص کرده باشد. بدون یک دامنه صریح، کوکی را نمیتوان با اطمینان با یک میزبان هدف تطبیق داد و ممکن است به روشهای غیرمنتظرهای اعمال شود. پیشنهاد میکنیم در عوض از قالب پرونده Netscape استفاده کنید.
کاربران اغلب میخواهند هم کوکیها را از یک پرونده بخوانند و هم کوکیهای بهروزشده را دوباره در پرونده بنویسند، بنابراین استفاده همزمان از هر دو گزینه --cookie و --cookie-jar در یک خط فرمان معمول است. curl نام پروندههای مشخصشده با --cookie را که وجود ندارند یا به یک دایرکتوری اشاره میکنند، نادیده میگیرد.
اگر curl با پشتیبانی از PSL (Public Suffix List) ساخته شده باشد، کوکیهایی را که برای چنین دامنههای پسوندی مشخص شدهاند و نباید مجاز به داشتن کوکی باشند، شناسایی و حذف میکند. اگر curl با پشتیبانی از PSL ساخته نشده باشد، هیچ تواناییای برای متوقف کردن سوپرکوکیها ندارد.
گزینه --cookie میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl -b "" https://example.com curl -b cookiefile https://example.com curl -b cookiefile -c cookiefile https://example.com curl -b name=Jane https://example.com
همچنین --cookie-jar و --junk-session-cookies را ببینید.
- -c, --cookie-jar <filename>
- (HTTP) فایلی را
مشخص کنید
که
میخواهید
curl پس از
تکمیل یک
عملیات،
تمام
کوکیها را
در آن
بنویسد. curl در
پایان
عملیات،
تمام
کوکیها را
از فضای
ذخیرهسازی
کوکی درون
حافظهٔ (in-memory)
خود در فایل
دادهشده
مینویسد.
حتی اگر هیچ
کوکیای
شناخته
نشده باشد،
فایلی
ایجاد
میشود تا
هرگونه
کوکی از قبل
موجود را از
فایل حذف
کند. این
فایل از
قالب فایل
کوکی Netscape
استفاده
میکند. اگر
نام فایل را
تنها یک خط
تیره، "-"،
قرار دهید،
کوکیها در
stdout نوشته
میشوند.
فایل مشخصشده با --cookie-jar فقط برای خروجی استفاده میشود. هیچ کوکیای از این فایل خوانده نمیشود. برای خواندن کوکیها، از گزینهٔ --cookie استفاده کنید. هر دو گزینه میتوانند فایل یکسانی را مشخص کنند.
این گزینهٔ خط فرمان، موتور کوکی را فعال میکند که باعث میشود curl کوکیها را ثبت کرده و از آنها استفاده کند. گزینهٔ --cookie نیز آن را فعال میکند.
اگر فایل ذخیرهٔ کوکی (cookie jar) ایجاد نشود یا امکان نوشتن در آن نباشد، کل عملیات curl با شکست مواجه نمیشود و حتی خطایی را بهطور واضح گزارش نمیکند. استفاده از --verbose باعث نمایش یک هشدار میشود، اما این تنها بازخورد قابل مشاهدهای است که دربارهٔ این وضعیت احتمالاً خطرناک دریافت میکنید.
ممکن است بخواهید umask خود را محدود کنید تا از دسترسی سایر کاربران در همان سیستم به فایل ایجادشده جلوگیری شود.
اگر --cookie-jar چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
curl -c store-here.txt https://example.com curl -c store-here.txt -b read-these https://example.com
همچنین ببینید --cookie و --junk-session-cookies.
- --create-dirs
- هنگامی که
در کنار
گزینهٔ --output
استفاده
شود، curl در
صورت نیاز
سلسلهمراتب
دایرکتوریهای
محلی لازم
را ایجاد
میکند. این
گزینه
دایرکتوریهای
ذکرشده در
گزینهٔ --output
را در ترکیب
با مسیری که
احتمالاً
با --output-dir
تنظیم شده
است ایجاد
میکند. اگر
نام فایل
خروجی
ترکیبشده
شامل هیچ
دایرکتوریای
نباشد، یا
اگر
دایرکتوریهای
ذکرشده از
قبل وجود
داشته
باشند، هیچ
دایرکتوریای
ایجاد
نمیشود.
دایرکتوریهای ایجادشده روی سیستمهای فایل به سبک یونیکس (Unix-style) با حالت 0750 ساخته میشوند.
برای ایجاد دایرکتوریهای راه دور هنگام استفاده از FTP یا SFTP، گزینهٔ --ftp-create-dirs را امتحان کنید.
مشخص کردن چندبارهٔ --create-dirs اثر اضافهای ندارد. با --no-create-dirs دوباره آن را غیرفعال کنید.
مثال:
curl --create-dirs --output local/dir/file https://example.com
همچنین ببینید --ftp-create-dirs و --output-dir.
- --create-file-mode <mode>
- (SFTP SCP FILE) هنگامی
که از curl برای
ایجاد
فایلها از
راه دور با
استفاده از
یکی از
پروتکلهای
پشتیبانیشده
استفاده
میشود،
این گزینه
به کاربر
امکان
میدهد
بهجای
حالت
پیشفرض 0644،
مشخص کند چه
'mode'ی در زمان
ایجاد روی
فایل تنظیم
شود.
این گزینه یک عدد در مبنای هشت (اکتال) را به عنوان آرگومان میپذیرد.
اگر --create-file-mode چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --create-file-mode 0777 -T localfile sftp://example.com/new
در نسخهٔ 7.75.0 اضافه شد. همچنین ببینید --ftp-create-dirs.
- --crlf
- (FTP SMTP) تبدیل خط
جدید (line feed) به
بازگشت به
ابتدای سطر
بههمراه
خط جدید (carriage return
بهعلاوهٔ
line feed) در هنگام
بارگذاری.
برای MVS (OS/390)
مفید است.
مشخص کردن چندبارهٔ --crlf اثر اضافهای ندارد. با --no-crlf دوباره آن را غیرفعال کنید.
مثال:
curl --crlf -T file ftp://example.com/
همچنین ببینید --use-ascii.
- --crlfile <file>
- (TLS) فایلی با
قالب PEM حاوی
فهرست
ابطال
گواهی (Certificate Revocation List)
ارائه
میدهد که
ممکن است
گواهیهای
همتا را که
باید
باطلشده
در نظر
گرفته
شوند، مشخص
کند.
اگر --crlfile چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --crlfile rejects.txt https://example.com
همچنین ببینید --cacert و --capath.
- --curves <list>
- (TLS) تنظیم
منحنیهای
مشخص برای
استفاده
هنگام
برقراری
نشست SSL بر
اساس RFC 8422، 5.1.
میتوان
چندین
الگوریتم
را با جدا
کردن آنها
با ":" ارائه
داد (مانند
"X25519:P-521"). این
پارامتر
بهطور
مشابه در
ابزارهای
"s_client" و "s_server" در
OpenSSL در دسترس
است.
--curves به نسخه curl مجهز به OpenSSL اجازه میدهد تا اتصالات SSL را دقیقاً با منحنی (EC) درخواستی کلاینت برقرار کند و از مذاکرات غیرشفاف کلاینت/سرور جلوگیری نماید.
اگر این گزینه تنظیم شود، فهرست پیشفرض منحنیهای تعبیهشده در OpenSSL نادیده گرفته میشود.
اگر --curves چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --curves X25519 https://example.com
در 7.73.0 اضافه شد. همچنین ببینید --ciphers.
- -d, --data <data>
- (HTTP MQTT) ارسال
دادههای
مشخصشده
به سرور.
برای HTTP(S)، این کار با متد POST به همان شیوهای انجام میشود که یک مرورگر هنگام پر کردن فرم HTML توسط کاربر و فشردن دکمه ارسال (submit) انجام میدهد. این گزینه باعث میشود curl دادهها را با استفاده از content-type به صورت application/x-www-form-urlencoded به سرور منتقل کند.
برای MQTT، دادهها به صورت یک PUBLISH ارسال میشوند.
--data-raw تقریباً مشابه است، اما تفسیر خاصی برای نویسه @ ندارد. برای ارسال دادهها بهصورت کاملاً باینری (دودویی)، باید در عوض از گزینه --data-binary استفاده کنید. برای URL-encode کردن مقدار یک فیلد فرم میتوانید از --data-urlencode استفاده کنید.
اگر هر یک از این گزینهها بیش از یک بار در همان خط فرمان استفاده شوند، بخشهای داده مشخصشده با نماد جداکننده - ادغام میشوند. بنابراین، استفاده از '-d name=daniel -d skill=lousy' یک قطعه post به صورت 'name=daniel&skill=lousy' تولید میکند.
اگر داده را با نویسه @ آغاز کنید، ادامه آن باید نام پروندهای باشد که دادهها از آن خوانده میشوند، یا - اگر میخواهید curl دادهها را از stdin بخواند. بنابراین، ارسال داده از پروندهای با نام 'foobar' با --data @foobar انجام میشود. هنگامی که به --data گفته میشود از چنین پروندهای بخواند، نویسههای carriage return، خطهای جدید (newlines) و بایتهای null حذف میشوند. اگر نمیخواهید نویسه @ تفسیر خاصی داشته باشد، به جای آن از --data-raw استفاده کنید.
دادههای این گزینه دقیقاً همانطور که در خط فرمان ارائه شدهاند به سرور منتقل میشوند. curl آنها را تبدیل، تغییر یا بهبود نمیدهد. ارائه دادهها به شکل صحیح بر عهده کاربر است.
--data میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl -d "name=curl" https://example.com curl -d "name=curl" -d "tool=cmdline" https://example.com curl -d @filename https://example.com
این گزینه با --form، --head و --upload-file مانعةالجمع است (همزمان قابل استفاده نیستند). همچنین ببینید --data-binary، --data-urlencode، --data-raw و --form.
- --data-ascii <data>
- (HTTP) این گزینه
یک نام
مستعار
برای --data است.
--data-ascii میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --data-ascii @file https://example.com
همچنین ببینید --data-binary، --data-raw و --data-urlencode.
- --data-binary <data>
- (HTTP) ارسال
دادهها (Post)
دقیقاً
همانگونه
که مشخص
شدهاند،
بدون
هیچگونه
پردازش
اضافی.
اگر داده را با نویسه @ آغاز کنید، ادامه آن باید نام یک پرونده باشد. "@-" باعث میشود curl دادهها را از stdin بخواند. دادهها به شیوهای مشابه با --data ارسال میشوند، به جز اینکه خطهای جدید (newlines) و بازگشت به ابتدای سطر (carriage returns) حفظ میشوند و هیچگونه تبدیلی انجام نمیشود.
مانند --data، نوع محتوای (content-type) پیشفرض ارسالشده به سرور application/x-www-form-urlencoded است. اگر میخواهید سرور با دادهها به عنوان دادههای باینری دلخواه رفتار کند، content-type را روی octet-stream تنظیم کنید: -H "Content-Type: application/octet-stream".
اگر این گزینه چندین بار استفاده شود، موارد پس از مورد نخست دادهها را همانگونه که در --data شرح داده شد الحاق (append) میکنند.
--data-binary میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --data-binary @filename https://example.com
همچنین ببینید --data-ascii.
- --data-raw <data>
- (HTTP) دادهها
را مشابه --data
ارسال (POST)
میکند،
اما بدون
تفسیر خاص
نویسه @.
--data-raw را میتوان چندین بار در یک خط فرمان به کار برد.
نمونهها:
curl --data-raw "hello" https://example.com curl --data-raw "@at@at@" https://example.com
همچنین ببینید --data.
- --data-urlencode <data>
- (HTTP) دادهها
را مشابه
سایر
گزینههای
--data ارسال (POST)
میکند، با
این استثنا
که این
گزینه URL-encoding را
انجام
میدهد.
برای سازگاری با CGI، بخش <data> باید با یک name آغاز شود و به دنبال آن یک جداکننده و مشخصه محتوا بیاید. بخش <data> را میتوان با یکی از نحوهای زیر به curl ارسال کرد:
- content
- محتوا را URL-encode کرده و آن را انتقال میدهد. دقت کنید که محتوا شامل هیچ نماد "=" یا "@" نباشد، زیرا باعث میشود نحو با یکی از حالتهای دیگر در زیر مطابقت پیدا کند.
- =content
- محتوا را URL-encode کرده و آن را انتقال میدهد. نماد پیشین "=" در دادهها گنجانده نمیشود.
- name=content
- بخش محتوا را URL-encode کرده و آن را انتقال میدهد. توجه داشته باشید که انتظار میرود بخش نام از پیش URL-encode شده باشد.
- @filename
- دادهها را از فایل دادهشده (شامل تمام خطوط جدید) بارگیری کرده، آن دادهها را URL-encode میکند و در POST انتقال میدهد. استفاده از "@-" باعث میشود curl دادهها را از stdin بخواند.
- name@filename
- دادهها را از فایل دادهشده (شامل تمام خطوط جدید) بارگیری کرده، آن دادهها را URL-encode میکند و در POST انتقال میدهد. یک علامت مساوی به بخش نام پیوست میشود که حاصل آن name=urlencoded-file-content خواهد بود. توجه داشته باشید که انتظار میرود بخش نام از پیش URL-encode شده باشد.
-
--data-urlencode را میتوان چندین بار در یک خط فرمان استفاده کرد.
نمونهها:
curl --data-urlencode name=val https://example.com curl --data-urlencode =encodethis https://example.com curl --data-urlencode name@file https://example.com curl --data-urlencode @fileonly https://example.com
همچنین ببینید --data و --data-raw.
- --delegation <LEVEL>
- (GSS/kerberos) تعیین میکند که curl در رابطه با اعتبارنامههای کاربر مجاز به تفویض چه سطحی (LEVEL) است.
-
اگر --delegation چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
نمونه:
curl --delegation "none" https://example.com
همچنین ببینید --insecure و --ssl.
- --digest
- (HTTP) احراز
هویت HTTP Digest را
فعال
میکند. این
طرح احراز
هویت از
ارسال
گذرواژه به
صورت متن
آشکار (clear text) از
طریق شبکه
جلوگیری
میکند. از
این گزینه
در ترکیب با
گزینه
معمولی --user
برای تنظیم
نام کاربری
و گذرواژه
استفاده
کنید.
مشخص کردن چندباره --digest هیچ اثر اضافهای ندارد. دوباره با --no-digest آن را غیرفعال کنید.
نمونه:
curl -u name:password --digest https://example.com
همچنین ببینید --user، --proxy-digest و --anyauth.
- -q, --disable
- اگر به
عنوان
نخستین
پارامتر در
خط فرمان
استفاده
شود، فایل
پیکربندی
curlrc خوانده
یا استفاده
نمیشود.
برای
جزئیات
مربوط به
مسیر
جستجوی
پیشفرض
فایل
پیکربندی
به --config
مراجعه
کنید.
مشخص کردن چندباره --disable هیچ اثر اضافهای ندارد. دوباره با --no-disable آن را غیرفعال کنید.
نمونه:
curl -q https://example.com
همچنین ببینید --config.
- --disable-eprt
- (FTP) غیرفعال
کردن
استفاده از
دستورهای EPRT
و LPRT هنگام
انجام
انتقالهای
فعال FTP. curl
معمولاً
پیش از
استفاده از
PORT، ابتدا
تلاش
میکند از EPRT
استفاده
کند، اما با
این گزینه،
بلافاصله
از PORT
استفاده
میکند. EPRT یک
افزونه
برای
پروتکل
اصلی FTP است و
روی همه
سرورها کار
نمیکند،
اما
قابلیتهای
بیشتری را
به شیوهای
بهتر از
دستور سنتی
PORT فراهم
میکند.
میتوان از --eprt برای فعالسازی صریح دوبارهٔ EPRT استفاده کرد و --no-eprt نام مستعاری برای --disable-eprt است.
اگر دسترسی به سرور با استفاده از IPv6 انجام شود، این گزینه هیچ تأثیری ندارد زیرا در این حالت EPRT ضروری است.
غیرفعال کردن EPRT تنها رفتار حالت فعال را تغییر میدهد. اگر میخواهید به حالت غیرفعال بروید، نباید از --ftp-port استفاده کنید یا اینکه آن را با --ftp-pasv اجبار نمایید.
ارائهٔ چندبارهٔ --disable-eprt تأثیر مضاعفی ندارد. غیرفعال کردن دوبارهٔ آن با --no-disable-eprt.
مثال:
curl --disable-eprt ftp://example.com/
همچنین ببینید --disable-epsv و --ftp-port.
- --disable-epsv
- (FTP) غیرفعال
کردن
استفاده از
دستور EPSV
هنگام
انجام
انتقالهای
غیرفعال FTP. curl
معمولاً
پیش از PASV،
ابتدا تلاش
میکند از EPSV
استفاده
کند، اما با
این گزینه،
EPSV را امتحان
نمیکند.
میتوان از --epsv برای فعالسازی صریح دوبارهٔ EPSV استفاده کرد و --no-epsv نام مستعاری برای --disable-epsv است.
اگر سرور یک میزبان IPv6 باشد، این گزینه هیچ تأثیری ندارد زیرا در این صورت EPSV ضروری است.
غیرفعال کردن EPSV تنها رفتار غیرفعال را تغییر میدهد. اگر میخواهید به حالت فعال تغییر وضعیت دهید، باید از --ftp-port استفاده کنید.
ارائهٔ چندبارهٔ --disable-epsv تأثیر مضاعفی ندارد. غیرفعال کردن دوبارهٔ آن با --no-disable-epsv.
مثال:
curl --disable-epsv ftp://example.com/
همچنین ببینید --disable-eprt و --ftp-port.
- --disallow-username-in-url
- در صورت
دریافت یک URL
حاوی نام
کاربری، با
خطا خارج
میشود. این
گزینه
احتمالاً
زمانی
بیشترین
کاربرد را
دارد که URL در
زمان اجرا
یا موارد
مشابه مشخص
شده باشد.
پذیرش و استفاده از اطلاعات اعتباری در یک URL معمولاً یک خطر امنیتی به شمار میرود، زیرا از این طریق به آسانی نشت پیدا میکنند.
ارائهٔ چندبارهٔ --disallow-username-in-url تأثیر مضاعفی ندارد. غیرفعال کردن دوبارهٔ آن با --no-disallow-username-in-url.
مثال:
curl --disallow-username-in-url https://example.com
همچنین ببینید --proto.
- --dns-interface <interface>
- (DNS) ارسال
درخواستهای
خروجی DNS از
طریق رابط
مشخصشده.
این گزینه
همتای --interface
است (که بر DNS
اثر
نمیگذارد).
رشتهٔ
ارائهشده
باید نام یک
رابط باشد
(نه یک
نشانی).
اگر --dns-interface چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --dns-interface eth0 https://example.com
برای کارکرد --dns-interface، لازم است که libcurl زیرین با قابلیت پشتیبانی از c-ares ساخته شده باشد. همچنین ببینید --dns-ipv4-addr و --dns-ipv6-addr.
- --dns-ipv4-addr <address>
- (DNS) مقید شدن
به یک نشانی
IP مشخص
هنگام
برقراری
درخواستهای
DNS از نوع IPv4،
به طوری که
درخواستهای
DNS از این
نشانی
سرچشمه
بگیرند.
آرگومان
باید یک
نشانی
منفرد IPv4
باشد.
اگر --dns-ipv4-addr چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --dns-ipv4-addr 10.1.2.3 https://example.com
برای کارکرد --dns-ipv4-addr، لازم است که libcurl زیرین با قابلیت پشتیبانی از c-ares ساخته شده باشد. همچنین ببینید --dns-interface و --dns-ipv6-addr.
- --dns-ipv6-addr <address>
- (DNS) هنگام
برقراری
درخواستهای
DNS از نوع IPv6،
به یک نشانی
IP مشخص متصل
میشود تا
درخواستهای
DNS از این
نشانی
سرچشمه
بگیرند.
آرگومان
باید یک
نشانی IPv6
منفرد باشد.
اگر --dns-ipv6-addr چند بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --dns-ipv6-addr 2a04:4e42::561 https://example.com
برای اینکه --dns-ipv6-addr کار کند، نیاز است که libcurl زیرین به همراه پشتیبانی از c-ares ساخته شده باشد. همچنین ببینید --dns-interface و --dns-ipv4-addr.
- --dns-servers <addresses>
- (DNS) فهرست
سرورهای DNS
مورد
استفاده به
جای
پیشفرض
سیستم را
تنظیم
میکند.
نشانیهای
IP در فهرست
باید با
کاما از هم
جدا شوند.
شمارههای
درگاه
(پورت) نیز
میتوانند
به صورت
اختیاری و
با دونقطه
در انتهای
نشانی IP
اضافه شوند.
اگر --dns-servers چند بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --dns-servers 192.168.0.1,192.168.0.2 https://example.com curl --dns-servers 10.0.0.1:53 https://example.com
برای اینکه --dns-servers کار کند، نیاز است که libcurl زیرین به همراه پشتیبانی از c-ares ساخته شده باشد. همچنین ببینید --dns-interface و --dns-ipv4-addr.
- --doh-cert-status
- (DNS) مشابه --cert-status
است اما
برای DoH (DNS-over-HTTPS)
استفاده
میشود.
وضعیت گواهی سرورهای DoH را با استفاده از افزونهٔ TLS به نام Certificate Status Request (معروف به OCSP stapling) بررسی میکند.
اگر این گزینه فعال باشد و سرور DoH پاسخی نامعتبر (مانند منقضیشده) ارسال کند، یا پاسخ نشان دهد که گواهی سرور باطل شده است، یا اصلاً هیچ پاسخی دریافت نشود، اعتبارسنجی با شکست مواجه میشود.
این پشتیبانی در حال حاضر فقط در بکاندهای OpenSSL و GnuTLS پیادهسازی شده است.
ارائهٔ چندبارهٔ --doh-cert-status هیچ اثر اضافهای ندارد. با --no-doh-cert-status میتوانید دوباره آن را غیرفعال کنید.
مثال:
curl --doh-cert-status --doh-url https://doh.example https://example.com
اضافهشده در 7.76.0. همچنین ببینید --doh-insecure.
- --doh-insecure
- (DNS) به طور
پیشفرض،
پیش از
انجام
فرایند
انتقال،
امن بودن هر
اتصالی که curl
با یک سرور DoH
برقرار
میکند
بررسی
میشود. این
گزینه به curl
میگوید از
مرحلهٔ
اعتبارسنجی
صرفنظر
کند و بدون
بررسی
ادامه دهد.
هشدار: استفاده از این گزینه فرایند انتقال DoH و تحلیل نام (name resolution) را ناامن میکند.
این گزینه معادل --insecure و --proxy-insecure است اما تنها برای DoH (DNS-over-HTTPS) به کار میرود.
ارائهٔ چندبارهٔ --doh-insecure هیچ اثر اضافهای ندارد. با --no-doh-insecure میتوانید دوباره آن را غیرفعال کنید.
مثال:
curl --doh-insecure --doh-url https://doh.example https://example.com
اضافهشده در 7.76.0. همچنین ببینید --doh-url، --insecure و --proxy-insecure.
- --doh-url <URL>
- (DNS) سرور DNS-over-HTTPS (DoH)
مورد نظر
برای تحلیل
نامهای
میزبان را
به جای
استفاده از
سازوکار
پیشفرض
تحلیلگر
نام مشخص
میکند.
نشانی
اینترنتی (URL)
باید HTTPS باشد.
برخی گزینههای SSL که برای انتقال خود تنظیم میکنید، برای DoH نیز اعمال میشوند چرا که جستجوی نامها از طریق SSL انجام میگیرد. تنظیمات اعتبارسنجی گواهی به ارث برده نمیشوند، بلکه به طور جداگانه از طریق --doh-insecure و --doh-cert-status کنترل میشوند.
به صورت پیشفرض، هنگام جستجوی اولیهٔ رکوردهای DNS مربوط به سرور DoH، از DoH صرفنظر میشود. برای اجتناب از این وضعیت میتوانید نشانی(های) IP سرور DoH را با --resolve مشخص کنید.
اگر یک رشتهٔ خالی "" به عنوان URL استفاده شود، این گزینه لغو تنظیم میشود. (اضافهشده در 7.85.0)
اگر --doh-url چند بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --doh-url https://doh.example https://example.com curl --doh-url https://doh.example --resolve doh.example:443:192.0.2.1 https://example.com
همچنین ببینید --doh-insecure.
- --dump-ca-embed
- (TLS) بستهی CA
جاسازیشده
در curl را در
خروجی
استاندارد
نوشته و سپس
خارج
میشود.
اگر curl بدون بستهی CA پیشفرضِ جاسازیشده ساخته شده باشد، خروجی خالی است.
ارائه دادن چندبارهی --dump-ca-embed اثر اضافهای ندارد. با --no-dump-ca-embed دوباره آن را غیرفعال کنید.
مثال:
curl --dump-ca-embed
در 8.10.0 افزوده شد. همچنین ببینید: --ca-native، --cacert، --capath، --proxy-ca-native، --proxy-cacert و --proxy-capath.
- -D, --dump-header <filename>
- (HTTP FTP)
سرایندهای
پروتکل
دریافتشده
را در فایل
مشخصشده
مینویسد.
اگر هیچ
سرایندی
دریافت
نشود،
استفاده از
این گزینه
یک فایل
خالی ایجاد
میکند.
برای نوشتن
در خروجی
استاندارد
(stdout)، مقدار "-"
(یک علامت
منفی منفرد)
را به عنوان
نام فایل
مشخص کنید.
از curl 8.10.0 به بعد، مشخص کردن "%" (یک علامت درصد منفرد) به عنوان نام فایل، خروجی را در stderr مینویسد.
هنگام استفاده در FTP، خطوط پاسخ سرور FTP به عنوان "سرایندها" تلقی شده و بنابراین در آنجا ذخیره میشوند.
از curl 8.11.0 به بعد، استفاده از گزینهی --create-dirs همچنین میتواند بخشهای ناموجود دایرکتوری را برای مسیر ارائهشده در --dump-header ایجاد کند.
داشتن چندین انتقال در یک مجموعه عملیات (یعنی URLها در یک عبارت --next)، آنها را با یک خط خالی جداکننده به انتهای همان فایل اضافه میکند.
اگر --dump-header چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
curl --dump-header store.txt https://example.com curl --dump-header - https://example.com -o save
همچنین ببینید: --output.
- --ech <config>
- (HTTPS) نحوهی
انجام ECH (Encrypted Client Hello)
را مشخص
میکند.
مقادیر مجاز برای <config> عبارتند از:
- false
- برای ECH تلاشی نمیکند. این مقدار پیشفرض است.
- grease
- ارسال یک افزونهی GREASE ECH
- true
- در صورت امکان برای ECH تلاش میکند، اما در صورتی که ECH انجام نشود ناموفق نمیشود. (اگر برای ECH تلاش شود ولی شکست بخورد، اتصال با شکست مواجه میشود.)
- hard
- برای ECH تلاش میکند و در صورت عدم امکان، با شکست مواجه میشود. ECH تنها با TLS 1.3 کار میکند و همچنین نیازمند استفاده از DoH یا ارائهی یک ECHConfigList در خط فرمان است.
- ecl:<b64val>
- یک ECHConfigList کدگذاریشده با base64 که برای ECH استفاده میشود.
- pn:<name>
- نامی برای بازنویسی (over-ride) فیلد "public_name" در یک ECHConfigList (تنها با پشتیبانی TLS در OpenSSL در دسترس است)
- بیشتر
خطاهای
مرتبط با ECH
باعث بروز
خطای CURLE_ECH_REQUIRED (101)
میشوند.
اگر --ech چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --ech true https://example.com
در 8.8.0 افزوده شد. همچنین ببینید: --doh-url.
- --egd-file <file>
- (TLS) گزینهی
منسوخشده
(افزوده در
7.84.0). پیش از
آن، تنها در
صورتی بر curl
تأثیر داشت
که برای
استفاده از
نسخههای
قدیمی OpenSSL
ساخته شده
باشد.
مسیر سوکت دیمن گردآوری آنتروپی (Entropy Gathering Daemon) را مشخص میکند. این سوکت برای مقداردهی اولیهی موتور تصادفی در اتصالات SSL استفاده میشود.
اگر --egd-file چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --egd-file /random/here https://example.com
همچنین ببینید: --random-file.
- --engine <name>
- (TLS) موتور
رمزنگاری OpenSSL
را برای
عملیات
رمزگذاری
انتخاب
میکند. از
"--engine list" برای
چاپ فهرستی
از
موتورهای
پشتیبانیشده
در زمان
ساخت
استفاده
کنید. توجه
داشته
باشید که
ممکن است
همهی (و
احتمالاً
هیچیک از)
موتورها در
زمان اجرا
در دسترس
نباشند.
مفهوم "engines" در OpenSSL با "providers" در OpenSSL 3 جایگزین شده است، و این گزینه برای مشخص کردن آنها نیز به خوبی کار میکند.
اگر --engine چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --engine flavor https://example.com
همچنین ببینید: --ciphers و --curves.
- --etag-compare <file>
- (HTTP) یک
درخواست
شرطی HTTP برای
ETag مشخص
خواندهشده
از پرونده
دادهشده،
با ارسال یک
سرآیند
سفارشی If-None-Match
با استفاده
از ETag
ذخیرهشده
برقرار
میکند.
برای نتایج درست، مطمئن شوید که پرونده مشخصشده تنها شامل یک خط با ETag مورد نظر است. با یک پرونده ناموجود یا خالی به عنوان یک ETag خالی برخورد میشود.
ابتدا از گزینه --etag-save برای ذخیره ETag از یک پاسخ استفاده کنید، و سپس از این گزینه برای مقایسه با ETag ذخیرهشده در درخواست بعدی استفاده کنید.
از این گزینه تنها با یک URL استفاده کنید.
اگر --etag-compare چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --etag-compare etag.txt https://example.com
در 7.68.0 اضافه شد. همچنین --etag-save و --time-cond را ببینید.
- --etag-save <file>
- (HTTP) یک ETag مربوط
به HTTP را در
پرونده
مشخصشده
ذخیره
میکند. یک ETag
یک سرآیند
مربوط به
حافظه
پنهان (caching)
است که
معمولاً در
پاسخ
بازگردانده
میشود. از
این گزینه
تنها با یک URL
استفاده
کنید.
اگر هیچ ETagای توسط سرور ارسال نشود، یک پرونده خالی ایجاد میشود.
در بسیاری از شرایط ممکن است بخواهید از یک etag موجود در درخواست استفاده کنید تا از بارگیری مجدد همان منبع جلوگیری شود، اما در عین حال در صورت تغییر واقعی آن، etag جدید را نیز ذخیره کنید؛ این کار با استفاده همزمان از هر دو گزینه etag یعنی --etag-save و --etag-compare با نام پرونده یکسان، در همان خط فرمان انجام میشود.
از نسخه curl 8.12.0، استفاده از گزینه --create-dirs همچنین میتواند مؤلفههای ناموجود دایرکتوری را برای مسیر ارائهشده در --etag-save ایجاد کند.
اگر --etag-save چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --etag-save storetag.txt https://example.com
در 7.68.0 اضافه شد. همچنین --etag-compare را ببینید.
- --expect100-timeout <seconds>
- (HTTP) حداکثر
زمان بر حسب
ثانیه که به
curl اجازه
میدهید
منتظر پاسخ
100-continue بماند،
هنگامی که curl
سرآیند Expects: 100-continue
را در
درخواست
خود ارسال
میکند.
بهطور
پیشفرض، curl
یک ثانیه
منتظر
میماند.
این گزینه
مقادیر
اعشاری را
میپذیرد.
وقتی curl از
انتظار دست
میکشد،
طوری ادامه
میدهد که
گویی پاسخی
دریافت شده
است.
مقدار اعشاری باید با استفاده از یک نقطه (".") به عنوان جداکننده اعشار ارائه شود - نه نگارش محلی، حتی اگر از جداکننده دیگری استفاده کند.
اگر --expect100-timeout چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --expect100-timeout 2.5 -T file https://example.com
همچنین --connect-timeout را ببینید.
- -f, --fail
- (HTTP) برای
انتقالهای
HTTP که کدهای
پاسخ HTTP
برابر با 400
یا بزرگتر
برمیگردانند،
با کد خطای 22
و بدون
هیچگونه
خروجی بدنه
پاسخ با
شکست مواجه
میشود.
در شرایط عادی، هنگامی که یک سرور HTTP در تحویل یک سند ناموفق باشد، بدنه متنیای حاوی اعلام این موضوع (که اغلب دلیل آن و موارد بیشتر را نیز توضیح میدهد) و یک کد پاسخ HTTP 4xx بازمیگرداند. این گزینه خط فرمان از خروجی دادن آن دادهها توسط curl جلوگیری کرده و در عوض زودتر خطای 22 را بازمیگرداند. بهطور پیشفرض، curl کدهای پاسخ HTTP را نشاندهنده شکست تلقی نمیکند.
برای دریافت کد خطا و همچنین ذخیره محتوا، در عوض از --fail-with-body استفاده کنید.
این روش کاملاً خطاناپذیر (fail-safe) نیست و مواردی پیش میآید که کدهای پاسخ ناموفق نادیده گرفته میشوند، بهویژه زمانی که احراز هویت در میان باشد (کدهای پاسخ 401 و 407).
ارائه چندباره --fail تأثیر اضافی ندارد. آن را دوباره با --no-fail غیرفعال کنید.
مثال:
curl --fail https://example.com
این گزینه با --fail-with-body ناسازگار (مانعةالجمع) است. همچنین --fail-with-body و --fail-early را ببینید.
- --fail-early
- با اولین
خطای
شناساییشده
در انتقال،
با شکست
مواجه شده و
خارج
میشود.
هنگامی که از curl برای انجام چندین انتقال در خط فرمان استفاده میشود، تلاش میکند روی تکتک URLهای دادهشده، یکی پس از دیگری عمل کند. بهطور پیشفرض، اگر URLهای بیشتری داده شده باشد خطاها را نادیده میگیرد و موفقیت آخرین URL تعیینکننده کد خطایی است که curl بازمیگرداند. شکستهای اولیه توسط انتقالهای موفق بعدی «پنهان» میشوند.
با استفاده از این گزینه، curl در عوض به محض شکست اولین انتقال، صرفنظر از تعداد URLهای ارائهشده در خط فرمان، یک خطا بازمیگرداند. بدین ترتیب، هیچ شکست انتقالی از دید اسکریپتها و موارد مشابه پنهان نمیماند.
این گزینه به معنای --fail نیست، که باعث میشود انتقالها به دلیل کد وضعیت HTTP سرور با شکست مواجه شوند. میتوانید این دو گزینه را با هم ترکیب کنید، با این حال توجه داشته باشید که --fail سراسری نیست و بنابراین توسط --next محدود میشود.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
ارائه چندباره --fail-early تأثیر اضافی ندارد. آن را دوباره با --no-fail-early غیرفعال کنید.
مثال:
curl --fail-early https://example.com https://two.example
همچنین --fail و --fail-with-body را ببینید.
- --fail-with-body
- (HTTP) در خطاهای
سرور که کد
پاسخ HTTP
برابر با 400
یا بیشتر
است، یک خطا
بازمیگرداند.
در حالت
عادی
هنگامی که
یک سرور HTTP در
ارائهٔ یک
سند با شکست
مواجه
میشود، یک
سند HTML
بازمیگرداند
که این
وضعیت را
گزارش
میکند (که
اغلب دلیل
آن و موارد
بیشتری را
نیز شرح
میدهد).
این گزینه
به curl اجازه
میدهد تا
آن محتوا را
در خروجی
نمایش داده
و ذخیره
کند، اما
همچنین کد
خطای 22 را
بازگرداند.
این گزینه، جایگزینی برای --fail است که باعث میشود curl در شرایط مشابه با خطا مواجه شود، اما بدون اینکه محتوا را ذخیره کند.
ارائهٔ چندبارهٔ --fail-with-body اثر اضافهای ندارد. با --no-fail-with-body دوباره آن را غیرفعال کنید.
مثال:
curl --fail-with-body https://example.com
این گزینه با --fail ناسازگار است. در نسخهٔ 7.76.0 اضافه شد. همچنین ببینید: --fail و --fail-early.
- --false-start
- (TLS) در حال
حاضر هیچ
بکاند TLS از
این قابلیت
پشتیبانی
نمیکند.
استفاده از شروع زودهنگام (false start) در طول دستتکانی TLS. شروع زودهنگام حالتی است که در آن کلاینت TLS پیش از اعتبارسنجی پیام Finished سرور، ارسال دادههای برنامه را آغاز میکند و بدین ترتیب هنگام انجام یک دستتکانی کامل، در یک رفتوبرگشت صرفهجویی میشود.
ارائهٔ چندبارهٔ --false-start اثر اضافهای ندارد. با --no-false-start دوباره آن را غیرفعال کنید.
مثال:
curl --false-start https://example.com
همچنین ببینید: --tcp-fastopen.
- --follow
- (HTTP) به curl دستور
میدهد تا
تغییرمسیرهای
HTTP را دنبال
کند و هنگام
دنبال کردن
تغییرمسیرها،
متد
درخواست
سفارشی
تنظیمشده
با --request را
همانطور
که مشخصات
فنی HTTP بیان
میکند
انجام دهد.
رشتهٔ متد تنظیمشده با --request در درخواستهای بعدی برای کدهای وضعیت 307 یا 308 استفاده میشود، اما ممکن است برای 301، 302 و 303 به GET بازنشانی شود.
این گزینه تفاوت ظریفی با --location دارد، زیرا آن گزینه همیشه متد سفارشی را صرفنظر از کد پاسخ در تمام درخواستهای بعدی تنظیم میکند.
پروتکلهایی را که یک تغییرمسیر مجاز به دنبال کردن آنها است با --proto-redir محدود کنید.
هنگامی که --netrc در ترکیب با این گزینه استفاده میشود، اطلاعات احراز هویت برای میزبانهای مقصد تغییرمسیر نیز ممکن است از آن پرونده انتخاب شود.
ارائهٔ چندبارهٔ --follow اثر اضافهای ندارد. با --no-follow دوباره آن را غیرفعال کنید.
مثال:
curl -X POST --follow https://example.com
در نسخهٔ 8.16.0 اضافه شد. همچنین ببینید: --request، --location، --proto-redir و --max-redirs.
- -F, --form <name=content>
- (HTTP SMTP IMAP) برای
خانوادهٔ
پروتکلهای
HTTP، یک فرم
پرشده را
شبیهسازی
میکند که
در آن کاربر
دکمهٔ
ارسال (submit) را
فشرده است.
این باعث
میشود curl
دادهها را
با استفاده
از Content-Type با
مقدار multipart/form-data
مطابق با RFC 2388
ارسال (POST) کند.
برای پروتکلهای SMTP و IMAP، این گزینه یک پیام ایمیل چندبخشی (multipart) را برای ارسال ایجاد میکند.
این گزینه بارگذاری پروندههای باینری و غیره را امکانپذیر میسازد. برای اجبار بخش 'content' به اینکه یک پرونده باشد، پیشوند نام پرونده را با علامت @ مشخص کنید. برای دریافت بخش محتوا از یک پرونده، پیشوند نام پرونده را با نماد < مشخص کنید. تفاوت بین @ و < در این است که @ باعث میشود پرونده به عنوان بارگذاری پرونده در ارسال ضمیمه شود، در حالی که < یک فیلد متنی ایجاد کرده و محتوای آن فیلد متنی را از یک پرونده دریافت میکند.
با استفاده از یک "-" تکی به عنوان نام پرونده، محتوا را به جای پرونده از stdin بخوانید. این موضوع برای هر دو ساختار @ و < صدق میکند. هنگامی که از stdin استفاده میشود، محتوا ابتدا توسط curl در حافظه بافر میشود تا اندازهٔ آن مشخص شود و امکان ارسال مجدد در صورت نیاز فراهم گردد. تعریف دادههای یک بخش از یک پروندهٔ غیرعادی نامگذاریشده (مانند لولهٔ نامگذاریشده یا مشابه آن) مشمول بافر شدن نیست و در عوض در زمان انتقال خوانده میشود؛ از آنجا که اندازهٔ کامل پیش از شروع انتقال مشخص نیست، چنین دادههایی در HTTP به صورت تکهتکه (chunks) ارسال شده و توسط IMAP رد میشوند.
مثال: ارسال یک تصویر به یک سرور HTTP، که در آن 'profile' نام فیلد فرم است که پروندهٔ portrait.jpg ورودی آن است:
curl -F profile=@portrait.jpg https://example.com/upload.cgi
مثال: ارسال نام و اندازهٔ کفش خود در دو فیلد متنی به سرور:
curl -F name=John -F shoesize=11 https://example.com
مثال: ارسال مقالهٔ خود در یک فیلد متنی به سرور. آن را به عنوان یک فیلد متنی ساده ارسال کنید، اما محتوای آن را از یک پروندهٔ محلی بگیرید:
curl -F "story=<hugefile.txt" https://example.com
همچنین میتوانید با استفاده از "type=" به روشی مشابه زیر، به curl مشخص کنید از چه Content-Type استفاده کند:
curl -F "web=@index.html;type=text/html" example.com
یا
curl -F "name=daniel;type=text/foo" example.com
همچنین میتوانید با تنظیم filename= نام فیلد بخش بارگذاری پرونده را صراحتاً تغییر دهید، مانند این:
curl -F "file=@localfile;filename=nameinpost" example.com
اگر نام پرونده/مسیر حاوی ',' یا ';' باشد، باید با نقلقول دوتایی (double-quotes) نقلقول شود، مانند:
curl -F "file=@\"local,file\";filename=\"name;in;post\"" \ https://example.comیا
curl -F 'file=@"local,file";filename="name;in;post"' \ https://example.comتوجه داشته باشید که اگر نام پرونده/مسیر در نقلقولهای دوتایی قرار گیرد، هر نقلقول دوتایی یا بکاسلش درون نام پرونده باید با بکاسلش گریز داده شود (escaped).
همچنین در صورتی که دادههای غیرپروندهای حاوی نقطه-ویرگول، فاصلههای ابتدا/انتها یا نقلقول دوتایی در ابتدا باشند، نقلقول باید اعمال شود:
curl -F 'colors="red; green; blue";type=text/x-myapp' \ https://example.com
میتوانید با تنظیم headers= سرآیندهای سفارشی به فیلد اضافه کنید، مانند
curl -F "submit=OK;headers=\"X-submit-type: OK\"" example.com
یا
curl -F "submit=OK;headers=@headerfile" example.com
کلیدواژه headers= ممکن است بیش از یک بار ظاهر شود و نکات بالا درباره نقلقول اعمال میشوند. هنگامی که سرآیندها از یک فایل خوانده میشوند، خطوط خالی و خطوطی که با '#' آغاز میشوند نادیده گرفته میشوند؛ هر سرآیند را میتوان با شکستن میان دو واژه و آغاز خط ادامه با یک فاصله تا کرد (fold نمود)؛ carriage-returnهای درونمتنی و فاصلههای انتهایی حذف میشوند. در اینجا نمونهای از محتوای یک فایل سرآیند آمده است:
# This file contains two headers. X-header-1: this is a header # The following header is folded. X-header-2: this is another header
برای پشتیبانی از ارسال پیامهای ایمیل multipart، نحو دستور به شرح زیر گسترش مییابد:
- نام میتواند حذف شود: علامت مساوی اولین نویسه آرگومان خواهد بود،
- اگر داده با '(' آغاز شود، نشاندهنده شروع یک multipart جدید است: میتواند با یک مشخصه content type دنبال شود.
- یک multipart میتواند با یک آرگومان '=)' پایان یابد.
مثال: دستور زیر یک ایمیل mime تحت SMTP ارسال میکند که شامل یک بخش درونخطی در دو قالب جایگزین است: plain text و HTML. این دستور یک فایل متنی را ضمیمه میکند:
curl -F '=(;type=multipart/alternative' \ -F '=plain text message' \ -F '= <body>HTML message</body>;type=text/html' \ -F '=)' -F '=@textfile.txt' ... smtp://example.comداده را میتوان با استفاده از encoder= برای انتقال کدگذاری کرد. کدگذاریهای موجود عبارتند از binary و 8bit که کاری جز افزودن سرآیند Content-Transfer-Encoding متناظر انجام نمیدهند، 7bit که تنها نویسههای 8-bit را با یک خطای انتقال رد میکند، و quoted-printable و base64 که دادهها را بر اساس طرحهای متناظر کدگذاری کرده و طول خطوط را به ۷۶ نویسه محدود میکنند.
مثال: ارسال ایمیل multipart با یک پیام متنی quoted-printable و یک فایل ضمیمهشده با base64:
curl -F '=text message;encoder=quoted-printable' \ -F '=@localfile;encoder=base64' ... smtp://example.com--form میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --form "name=curl" --form "file=@loadthis" https://example.com
این گزینه با --data، --head و --upload-file مانعةالجمع است. همچنین ببینید --data، --form-string و --form-escape.
- --form-escape
- (HTTP IMAP SMTP) نام
فیلدهای
فرم multipart و
فایلها را
بهجای percent-encoding
با استفاده
از backslash-escaping
ارسال
میکند.
اگر --form-escape چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --form-escape -F 'field\name=curl' -F 'file=@load"this' https://example.com
در 7.81.0 اضافه شد. همچنین ببینید --form.
- --form-string <name=string>
- (HTTP SMTP IMAP) مشابه --form
است، با این
تفاوت که
رشتهٔ
مقدار برای
پارامترِ
نامبرده
به صورت
تحتاللفظی
به کار
میرود.
نویسههای
آغازین @ و < و
رشتهٔ ";type="
در مقدار
هیچ معنای
خاصی
ندارند. اگر
این احتمال
وجود دارد
که مقدار
رشته
تصادفاً
قابلیتهای
@ یا < در --form را
فعال کند،
استفاده از
این گزینه
را به --form
ترجیح دهید.
--form-string میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --form-string "name=data" https://example.com
همچنین ببینید: --form.
- --ftp-account <data>
- (FTP) هنگامی که
یک سرور FTP پس
از ارائهٔ
نام کاربری
و گذرواژه،
درخواست "account
data" میکند،
این داده با
استفاده از
دستور ACCT
ارسال
میشود.
اگر --ftp-account چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ftp-account "mr.robot" ftp://example.com
همچنین ببینید: --user.
- --ftp-alternative-to-user <command>
- (FTP) اگر احراز
هویت با
دستورهای USER
و PASS شکست
بخورد، این
دستور
ارسال
میشود.
هنگام
اتصال به
سرور Tumbleweed's Secure Transport
از طریق FTPS با
استفاده از
گواهی
کلاینت،
استفاده از
"SITE AUTH" به سرور
اعلام
میکند که
نام کاربری
را از گواهی
بازیابی
کند.
اگر --ftp-alternative-to-user چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ftp-alternative-to-user "U53r" ftp://example.com
همچنین ببینید: --ftp-account و --user.
- --ftp-create-dirs
- (FTP SFTP) هنگامی
که یک
عملیات یا URL
در FTP یا SFTP از
مسیری
استفاده
میکند که
در حال حاضر
روی سرور
وجود
ندارد،
رفتار
پیشفرض curl
شکست در
عملیات است.
با استفاده
از این
گزینه، curl در
عوض تلاش
میکند
دایرکتوریهای
ناموجود را
ایجاد کند.
مشخص کردن چندبارهٔ --ftp-create-dirs تأثیر اضافهای ندارد. غیرفعال کردن دوبارهٔ آن با --no-ftp-create-dirs انجام میشود.
مثال:
curl --ftp-create-dirs -T file ftp://example.com/remote/path/file
همچنین ببینید: --create-dirs.
- --ftp-method <method>
- (FTP) مشخص میکند که curl باید از چه روشی برای دسترسی به یک فایل روی سرور FTP(S) استفاده کند. آرگومان method باید یکی از گزینههای جایگزین زیر باشد:
- multicwd
- برای هر بخش از مسیر در URL دادهشده، یک عملیات CWD منفرد انجام میدهد. برای سلسلهمراتبهای عمیق، این کار به معنای دستورهای بسیار است. طبق گفتهٔ RFC 1738 این کار باید به همین شیوه انجام شود. این حالت رفتار پیشفرض است، اما کندترین رفتار به شمار میرود.
- nocwd
- به هیچ عنوان CWD انجام نمیدهد. curl دستورهای SIZE، RETR، STOR و غیره را اجرا کرده و برای هر یک از این دستورها مسیر کامل را به سرور میدهد. این سریعترین رفتار است.
- singlecwd
- یک CWD با کل دایرکتوری مقصد انجام میدهد و سپس "بهطور معمول" (مانند حالت multicwd) روی فایل عمل میکند. این روش تا حدودی بیشتر از "nocwd" با استانداردها سازگار است، اما جریمهٔ کامل کارایی در "multicwd" را ندارد.
-
اگر --ftp-method چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --ftp-method multicwd ftp://example.com/dir1/dir2/file curl --ftp-method nocwd ftp://example.com/dir1/dir2/file curl --ftp-method singlecwd ftp://example.com/dir1/dir2/file
همچنین ببینید: --list-only.
- --ftp-pasv
- (FTP) از حالت
غیرفعال (passive)
برای اتصال
داده
استفاده
میکند.
حالت
غیرفعال،
رفتار
پیشفرض
داخلی است،
اما
استفاده از
این گزینه
میتواند
برای
نادیده
گرفتن
گزینهٔ
قبلی --ftp-port به
کار رود.
بازگرداندن حالت غیرفعالِ اجباری واقعاً امکانپذیر نیست، بلکه در عوض باید دوباره گزینهٔ --ftp-port درست را اعمال کنید.
حالت غیرفعال بدین معناست که curl ابتدا دستور EPSV و سپس PASV را امتحان میکند، مگر اینکه --disable-epsv استفاده شده باشد.
مشخص کردن چندبارهٔ --ftp-pasv تأثیر اضافهای ندارد.
مثال:
curl --ftp-pasv ftp://example.com
این گزینه با --ftp-port مانعةالجمع است. همچنین ببینید: --disable-epsv.
- -P, --ftp-port <address>
- (FTP) معکوس کردن نقشهای پیشفرض آغازگر/شنونده هنگام اتصال با FTP. این گزینه باعث میشود curl از حالت فعال (active mode) استفاده کند. سپس curl به سرور دستور میدهد که به نشانی و پورت مشخصشدهی کلاینت متصل شود، در حالی که حالت غیرفعال (passive mode) از سرور میخواهد یک نشانی IP و پورت برای اتصال به آن برپا کند. <address> باید یکی از موارد زیر باشد:
- interface
- برای نمونه eth0 برای مشخص کردن اینکه میخواهید از نشانی IP کدام رابط استفاده کنید (تنها در یونیکس)
- IP address
- برای نمونه 192.168.10.1 برای مشخص کردن نشانی دقیق IP
- hostname
- برای نمونه my.host.domain برای مشخص کردن ماشین میزبان
- -
- باعث میشود curl همان نشانی IP را انتخاب کند که پیشتر برای اتصال کنترلی استفاده شده است. این انتخاب، گزینهی توصیهشده است.
- غیرفعال
کردن
استفاده از
PORT با --ftp-pasv.
غیرفعال
کردن تلاش
برای
استفاده از
دستور EPRT به
جای PORT با
استفاده از
--disable-eprt. دستور EPRT
در واقع
همان PORT++ است.
شما همچنین میتوانید ":[start]-[end]" را به سمت راست نشانی اضافه کنید، تا به curl بگویید از چه بازه پورت TCP استفاده کند. این بدان معناست که شما یک بازه پورت، از یک شماره کمتر به بیشتر را مشخص میکنید. یک شماره تکی نیز کار میکند، اما توجه داشته باشید که ریسک شکست را افزایش میدهد زیرا ممکن است آن پورت در دسترس نباشد.
اگر --ftp-port چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
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) ارسال
دستور PRET پیش
از PASV (و EPSV). برخی
سرورهای FTP،
عمدتاً drftpd،
برای
فهرستگیری
دایرکتوری
و همچنین
بارگذاری و
بارگیری در
حالت PASV به
این دستور
غیر
استاندارد
نیاز دارند.
مشخص کردن چندبارهی --ftp-pret هیچ اثر اضافی ندارد. آن را مجدداً با --no-ftp-pret غیرفعال کنید.
مثال:
curl --ftp-pret ftp://example.com
همچنین ببینید --ftp-port و --ftp-pasv.
- --ftp-skip-pasv-ip
- (FTP) هنگام
برقراری
اتصال داده
توسط curl، از
نشانی IP که
سرور در
پاسخ به
دستور PASV
برنامه curl
پیشنهاد
میدهد
استفاده
نکنید. در
عوض curl از
همان نشانی
IP که پیشتر
برای اتصال
کنترلی
استفاده
کرده است،
دوباره
استفاده
میکند.
این گزینه به صورت پیشفرض فعال است (در نسخهی 7.74.0 اضافه شد).
اگر به جای PASV از PORT، EPRT یا EPSV استفاده شود، این گزینه هیچ اثری ندارد.
مشخص کردن چندبارهی --ftp-skip-pasv-ip هیچ اثر اضافی ندارد. آن را مجدداً با --no-ftp-skip-pasv-ip غیرفعال کنید.
مثال:
curl --ftp-skip-pasv-ip ftp://example.com
همچنین ببینید --ftp-pasv.
- --ftp-ssl-ccc
- (FTP) استفاده
از CCC (کانال
شفاف فرمان
/ Clear Command Channel). لایهی
SSL/TLS را پس از
احراز هویت
خاموش
میکند.
ادامهی
ارتباطات
کانال
کنترلی
بدون
رمزگذاری
خواهد بود.
این کار به
روترهای NAT
اجازه
میدهد
تراکنش FTP را
دنبال کنند.
حالت
پیشفرض passive
است.
مشخص کردن چندبارهی --ftp-ssl-ccc هیچ اثر اضافی ندارد. آن را مجدداً با --no-ftp-ssl-ccc غیرفعال کنید.
مثال:
curl --ftp-ssl-ccc ftps://example.com
همچنین ببینید --ssl و --ftp-ssl-ccc-mode.
- --ftp-ssl-ccc-mode <active/passive>
- (FTP) تنظیم
حالت CCC. حالت
passive
خاموشسازی
را آغاز
نمیکند،
بلکه منتظر
میماند تا
سرور این
کار را
انجام دهد،
و به
خاموشسازی
از طرف سرور
پاسخی
نمیدهد.
حالت active
خاموشسازی
را آغاز
کرده و
منتظر
پاسخی از
طرف سرور
میماند.
مشخص کردن چندبارهی --ftp-ssl-ccc-mode هیچ اثر اضافی ندارد. آن را مجدداً با --no-ftp-ssl-ccc-mode غیرفعال کنید.
مثال:
curl --ftp-ssl-ccc-mode active --ftp-ssl-ccc ftps://example.com
همچنین ببینید --ftp-ssl-ccc.
- --ftp-ssl-control
- (FTP) الزام
استفاده از
SSL/TLS برای ورود
به FTP، و
ارسال شفاف
(رمزگذارینشده)
برای
انتقال
دادهها.
این گزینه
احراز هویت
امن را
امکانپذیر
میسازد،
اما برای
کارایی
بیشتر،
دادهها را
بدون
رمزگذاری
منتقل
میکند. اگر
سرور از SSL/TLS
پشتیبانی
نکند،
انتقال با
شکست مواجه
میشود.
در صورت تنظیم، این گزینه بر --ssl تقدم دارد.
ارائه چندباره --ftp-ssl-control تأثیر اضافهای ندارد. با --no-ftp-ssl-control دوباره آن را غیرفعال کنید.
مثال:
curl --ftp-ssl-control ftp://example.com
همچنین ببینید --ssl.
- -G, --get
- (HTTP) هنگام
استفاده،
این گزینه
باعث
میشود
تمام
دادههای
مشخصشده
با --data، --data-binary
یا --data-urlencode به
جای
درخواست POST
که در غیر
این صورت
استفاده
میشد، در
یک درخواست
HTTP GET به کار
بروند. curl
دادههای
ارائهشده
را به عنوان
یک رشته
جستار (query string) به
نشانی
اینترنتی (URL)
پیوست
میکند.
در صورت استفاده در ترکیب با --head، دادههای POST در عوض همراه با یک درخواست HEAD به نشانی اینترنتی پیوست میشوند.
ارائه چندباره --get تأثیر اضافهای ندارد. با --no-get دوباره آن را غیرفعال کنید.
مثالها:
curl --get https://example.com curl --get -d "tool=curl" -d "age=old" https://example.com curl --get -I -d "tool=curl" https://example.com
همچنین ببینید --data و --request.
- -g, --globoff
- قابلیت
تطبیق الگو
(globbing) در URL را
غیرفعال
میکند.
هنگامی که
این گزینه
را تنظیم
میکنید،
میتوانید
نشانیهای
اینترنتی
حاوی
نویسههای
{}[] را بدون
این که خود curl
آنها را
تفسیر کند،
مشخص کنید.
توجه داشته
باشید که
این
نویسهها
محتوای
قانونی و
معمول URL
نیستند و
باید مطابق
با
استاندارد
URI کدگذاری
شوند.
هنگامی که نشانیهای عددی IPv6 در URL استفاده میشوند، curl آنها را تشخیص داده و از این قاعده مستثنی میکند، بنابراین همچنان میتوان بدون نیاز به غیرفعالسازی globbing از آنها استفاده کرد.
ارائه چندباره --globoff تأثیر اضافهای ندارد. با --no-globoff دوباره آن را غیرفعال کنید.
مثال:
curl -g "https://example.com/{[]}}}}"همچنین ببینید --config و --disable.
- --happy-eyeballs-timeout-ms <ms>
- تنظیم مهلت
زمانی (timeout)
برای Happy Eyeballs.
الگوریتم Happy Eyeballs سازوکاری است که برای میزبانهای دوپشتهای (dual-stack) تلاش میکند به هر دو نشانی IPv4 و IPv6 متصل شود، و به IPv6 به اندازه تعداد میلیثانیههای مشخصشده فرجه زمانی اولیه میدهد. اگر در این مدت اتصال به نشانی IPv6 برقرار نشود، تلاش برای برقراری اتصال به نشانی IPv4 به طور موازی انجام میگیرد. نخستین اتصالی که برقرار شود، همان اتصالی است که استفاده خواهد شد.
محدوده مقادیر مفید پیشنهادی محدود است. در RFC 6555 مربوط به Happy Eyeballs آمده است: "توصیه میشود که تلاشهای برقراری اتصال با فاصله 150-250 ms از یکدیگر زمانبندی شوند تا بین عوامل انسانی و بار شبکه تعادل برقرار گردد." در حال حاضر پیشفرض libcurl برابر 200 ms است. پیشفرض Firefox و Chrome در حال حاضر 300 ms است.
اگر --happy-eyeballs-timeout-ms چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثال:
curl --happy-eyeballs-timeout-ms 500 https://example.com
همچنین ببینید --max-time و --connect-timeout.
- --haproxy-clientip <ip>
- (HTTP) یک IP
کلاینت را
در سربرگ
پروتکل HAProxy PROXY
نسخه 1 در
ابتدای
اتصال
تنظیم
میکند.
برای درخواستهای معتبر، نشانیهای IPv4 باید دقیقاً به صورت دنبالهای از ۴ عدد صحیح در محدوده شامل [0..255] با نمایش دهدهی مشخص شوند که دقیقاً با یک نقطه از یکدیگر جدا شدهاند. صفرهای ابتدایی پیش از اعداد مجاز نیستند تا از هرگونه ابهام احتمالی با اعداد در مبنای ۸ (اکتال) جلوگیری شود. نشانیهای IPv6 باید به صورت دنبالهای از ۴ رقم هگزادسیمال (حروف بزرگ یا کوچک) مشخص شوند که با دونقطه از یکدیگر جدا شدهاند، همراه با پذیرش یک توالی دونقطهٔ دوتایی برای جایگزینی بزرگترین محدوده مجاز از صفرهای متوالی. تعداد کل بیتهای رمزگشاییشده باید دقیقاً ۱۲۸ باشد.
در غیر این صورت، هر رشتهای میتواند برای IP کلاینت پذیرفته و ارسال شود.
در صورت استفاده، این گزینه جایگزین --haproxy-protocol میشود و نیازی به مشخص کردن هر دو گزینه نیست.
اگر --haproxy-clientip چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثال:
curl --haproxy-clientip $IP
در نسخه 8.2.0 اضافه شد. همچنین ببینید --proxy.
- --haproxy-protocol
- (HTTP) در ابتدای
اتصال، یک
هدر HAProxy PROXY protocol v1
ارسال
میکند. این
مورد توسط
برخی از
متعادلکنندههای
بار و
پروکسیهای
معکوس برای
مشخص کردن
نشانی IP و
پورت واقعی
کلاینت
استفاده
میشود.
این گزینه در درجه اول هنگام ارسال درخواستهای آزمایشی به سرویسی که انتظار این هدر را دارد، مفید است.
ارائه چندباره --haproxy-protocol تأثیر اضافهای ندارد. با --no-haproxy-protocol دوباره آن را غیرفعال کنید.
مثال:
curl --haproxy-protocol https://example.com
همچنین ببینید --proxy.
- -I, --head
- (HTTP FTP FILE) تنها
هدرها را
دریافت
میکند.
سرورهای HTTP
دارای
دستور HEAD
هستند که
این گزینه
برای
دریافت
چیزی جز هدر
یک سند از
آن استفاده
میکند.
هنگام
استفاده
روی یک URL با
پروتکل FTP یا
FILE، ابزار curl
تنها
اندازه
فایل و زمان
آخرین
تغییر را
نمایش
میدهد.
ارائه چندباره --head تأثیر اضافهای ندارد. با --no-head دوباره آن را غیرفعال کنید.
مثال:
curl -I https://example.com
همچنین ببینید --get، --verbose و --trace-ascii.
- -H, --header <header/@file>
- (HTTP IMAP SMTP) هدر
اضافی برای
گنجاندن در
اطلاعات
ارسالی.
هنگام
استفاده
درون یک
درخواست HTTP،
به هدرهای
معمول
درخواست
اضافه
میشود.
برای یک ایمیل آپلودشده با قالب MIME در IMAP یا SMTP که با گزینههای --form ساخته شده باشد، این هدر به ابتدای سند MIME حاصل اضافه میشود و عملاً آن را در سطح سراسری ایمیل میگنجاند. این مورد روی ایمیلهای خام آپلودشده تأثیری ندارد.
شما میتوانید هر تعداد هدر اضافی را مشخص کنید. توجه داشته باشید اگر یک هدر سفارشی اضافه کنید که نام آن با یکی از هدرهای داخلی مورد استفاده curl یکسان باشد، هدر تنظیمشده خارجی شما بهجای هدر داخلی استفاده خواهد شد. این به شما امکان میدهد کارهای ظریفتر و پیچیدهتری نسبت به آنچه curl بهطور معمول انجام میدهد، انجام دهید. نباید هدرهای تنظیمشده داخلی را جایگزین کنید مگر اینکه کاملاً بدانید چه کاری انجام میدهید. با تعیین یک جایگزین بدون محتوا در سمت راست دونقطه، یک هدر داخلی را حذف کنید؛ مانند: -H "Host:". اگر هدر سفارشی را بدون مقدار ارسال میکنید، آنگاه هدر باید با یک نقطهویرگول پایان یابد؛ مانند -H "X-Custom-Header;" برای ارسال "X-Custom-Header:".
ابزار curl اطمینان حاصل میکند که هر هدر اضافهشده/جایگزینشده با نشانگر انتهای خط مناسب ارسال شود، بنابراین نباید آن را به عنوان بخشی از محتوای هدر اضافه کنید: خطوط جدید یا نویسههای بازگشت به اول خط (carriage return) اضافه نکنید، زیرا آنها فقط کار را برای شما خراب میکنند. curl رشته متنی ارائهشده توسط شما را عیناً بدون هیچ فیلتر یا سایر تدابیر ایمنی ارسال میکند. این شامل فاصلههای خالی و نویسههای کنترلی نیز میشود.
این گزینه میتواند آرگومانی به سبک @filename بپذیرد که در این صورت برای هر سطر در فایل ورودی، یک هدر اضافه میکند. استفاده از @- باعث میشود curl فایل هدر را از stdin بخواند.
لطفاً توجه داشته باشید که بیشتر ابزارهای ضد هرزنامه، وجود و مقدار چندین هدر ایمیل MIME را بررسی میکنند: از جمله این هدرها میتوان به "From:"، "To:"، "Date:" و "Subject:" اشاره کرد که باید با این گزینه اضافه شوند.
برای ارسال هدرهای سفارشی در نظر گرفتهشده برای یک پروکسی HTTP، به --proxy-header نیاز دارید.
ارسال هدر "Transfer-Encoding: chunked" هنگام انجام یک درخواست HTTP همراه با بدنه درخواست، باعث میشود curl دادهها را با استفاده از کدگذاری تکهتکه (chunked encoding) ارسال کند.
هشدار: هدرهای تنظیمشده با این گزینه در تمام درخواستهای HTTP تنظیم میشوند - حتی پس از دنبال کردن تغییر مسیرها، مانند زمانی که با --location مشخص شده باشد. این میتواند منجر به ارسال هدر به میزبانهایی غیر از میزبان اصلی شود، بنابراین هدرهای حساس در صورت ترکیب با دنبال کردن تغییر مسیرها باید با احتیاط استفاده شوند.
هدرهای "Authorization:" و "Cookie:" هنگام دنبال کردن تغییر مسیرها به مبداهای دیگر، صراحتاً در درخواستهای HTTP ارسال نمیشوند، مگر اینکه از --location-trusted استفاده شود.
--header میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl -H "X-First-Name: Joe" https://example.com curl -H "User-Agent: yes-please/2000" https://example.com curl -H "Host:" https://example.com curl -H @headers.txt https://example.com
همچنین ببینید --user-agent، --referer و --proxy-header.
- -h, --help <subject>
- راهنمای
استفاده.
برای
موضوعی که
به عنوان یک
آرگومان
اختیاری
داده
میشود،
راهنما
ارائه
میدهد.
اگر هیچ آرگومانی ارائه نشود، curl مهمترین آرگومانهای خط فرمان را نمایش میدهد.
این آرگومان میتواند یک دستهبندی یا یک گزینه خط فرمان باشد. هنگامی که یک دستهبندی ارائه شود، curl تمام گزینههای خط فرمان درون آن دستهبندی را نشان میدهد. برای فهرست کردن همه گزینههای موجود، دستهبندی "all" را مشخص کنید.
اگر "category" مشخص شود، curl تمام دستهبندیهای راهنمای موجود را نمایش میدهد.
اگر موضوع ارائهشده در عوض یک گزینه خط فرمان موجود باشد، که یا به شکل کوتاه با یک خط تیره و یک حرف یا به شکل بلند با دو خط تیره و یک نام طولانیتر مشخص شده باشد، curl متن راهنما را برای آن گزینه در ترمینال نمایش میدهد.
خروجی راهنما برای برخی از گزینهها مفصل است.
اگر گزینه خط فرمان ارائهشده ناشناخته باشد، curl این موضوع را اعلام میکند.
مثالها:
curl --help all curl --help --insecure curl --help -f
همچنین ببینید --verbose.
- --hostpubmd5 <md5>
- (SFTP SCP) یک رشته
حاوی ۳۲ رقم
هگزادسیمال
ارسال کنید.
این رشته
باید چکسام
۱۲۸ بیتی MD5
از کلید
عمومی
میزبان
دوردست
باشد؛ curl
اتصال به
میزبان را
رد میکند
مگر اینکه
چکسامها
مطابقت
داشته
باشند.
اگر --hostpubmd5 چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --hostpubmd5 e5c1c49020640a5ab0f2034854c321a8 sftp://example.com/
همچنین --hostpubsha256 را ببینید.
- --hostpubsha256 <sha256>
- (SFTP SCP) یک رشته
حاوی هش SHA256
کدگذاریشده
با Base64 از کلید
عمومی
میزبان
دوردست
ارسال کنید.
curl اتصال به
میزبان را
رد میکند
مگر اینکه
هشها
مطابقت
داشته
باشند.
اگر --hostpubsha256 چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --hostpubsha256 NDVkMTQxMGQ1ODdmMjQ3MjczYjAyOTY5MmRkMjVmNDQ= sftp://example.com/
در 7.80.0 اضافه شد. همچنین --hostpubmd5 را ببینید.
- --hsts <filename>
- (HTTPS) قابلیت HSTS
را برای
انتقال
فعال کنید.
اگر نام
فایل به یک
فایل کش HSTS
موجود
اشاره کند،
از آن
استفاده
میشود. پس
از تکمیل
انتقال، در
صورتی که کش
تغییر
یافته
باشد،
دوباره در
فایل ذخیره
میشود. اگر
چندین
اجرای curl را
به طور
همزمان با
استفاده از
یک فایل کش HSTS
اجرا کنید،
ممکن است به
شیوههای
ناخواستهای
با یکدیگر
تداخل پیدا
کنند.
اگر به curl گفته شود که برای انتقالی شامل نام میزبانی که در کش HSTS وجود دارد از "http://" استفاده کند، انتقال را به استفاده از HTTPS ارتقا میدهد. هر ورودی کش HSTS دارای طول عمر مشخصی است که پس از پایان آن، ارتقا دیگر انجام نمیشود.
یک نام فایل "" (با طول صفر) مشخص کنید تا از بارگذاری/ذخیرهسازی جلوگیری شده و curl مدیریت HSTS را در حافظه انجام دهد.
شاید بخواهید umask خود را محدود کنید تا از دسترسی سایر کاربران همان سیستم به فایل ایجادشده جلوگیری شود.
اگر این گزینه چندین بار استفاده شود، curl محتوای تمام فایلها را بارگذاری میکند، اما آخرین فایل برای ذخیرهسازی استفاده میشود.
از curl 8.20.0 به بعد، curl حداکثر ۱۰٬۰۰۰ نام میزبان یکتای HSTS را که اخیراً اضافه شدهاند نگهداری میکند.
--hsts میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --hsts cache.txt https://example.com
در 7.74.0 اضافه شد. همچنین --proto را ببینید.
- --http0.9
- (HTTP) یک پاسخ
نسخه 0.9
پروتکل HTTP را
بپذیرید.
HTTP/0.9 پاسخی بدون سرایند است و بنابراین میتوانید با این گزینه به سرورهای غیر HTTP نیز متصل شده و همچنان پاسخ دریافت کنید، چرا که curl - در صورت مجاز بودن - به طور شفاف به نسخه پایینتر تنزل مییابد.
HTTP/0.9 به طور پیشفرض غیرفعال است (در 7.66.0 اضافه شد)
ارائه چندباره --http0.9 تأثیر اضافهای ندارد. با --no-http0.9 دوباره آن را غیرفعال کنید.
مثال:
curl --http0.9 https://example.com
همچنین --http1.1، --http2 و --http3 را ببینید.
- -0, --http1.0
- (HTTP) از نسخه 1.0
پروتکل HTTP به
جای نسخه
ترجیحی
داخلی آن
استفاده
کنید.
ارائه چندباره --http1.0 تأثیر اضافهای ندارد.
مثال:
curl --http1.0 https://example.com
این گزینه با --http1.1، --http2، --http2-prior-knowledge و --http3 مانعةالجمع است. همچنین --http0.9 و --http1.1 را ببینید.
- --http1.1
- (HTTP) از نسخه 1.1
پروتکل HTTP
استفاده
کنید. این
حالت
پیشفرض
برای
نشانیهای
"http://" است.
ارائه چندباره --http1.1 تأثیر اضافهای ندارد.
مثال:
curl --http1.1 https://example.com
این گزینه با --http1.0، --http2، --http2-prior-knowledge و --http3 مانعةالجمع است. همچنین --http1.0 و --http0.9 را ببینید.
- --http2
- (HTTP) استفاده
از HTTP/2.
برای HTTPS، این بدان معناست که curl در مصافحه TLS بر سر HTTP/2 مذاکره میکند. curl این کار را به صورت پیشفرض انجام میدهد.
برای HTTP، این بدان معناست که curl تلاش میکند با استفاده از سرآیند درخواست Upgrade:، درخواست را به HTTP/2 ارتقا دهد.
هنگامی که curl از HTTP/2 روی HTTPS استفاده میکند، خود بر روی TLS 1.2 یا بالاتر اصرار نمیورزد حتی اگر این مورد در مشخصات الزامی شده باشد. کاربر میتواند این الزام نسخه را با --tlsv1.2 اضافه کند.
ارائه چندباره --http2 اثر اضافهای ندارد.
مثال:
curl --http2 https://example.com
برای کارکردن --http2، لازم است که libcurl زیرین با پشتیبانی از HTTP/2 ساخته شده باشد. این گزینه با --http1.1، --http1.0، --http2-prior-knowledge و --http3 مانعةالجمع است. همچنین --http1.1، --http3، --no-alpn و --proxy-http2 را ببینید.
- --http2-prior-knowledge
- (HTTP) ارسال یک
درخواست HTTP
بدون TLS با
استفاده
مستقیم از HTTP/2
بدون
ارتقای HTTP/1.1.
این کار
نیازمند
آگاهی قبلی
از این است
که سرور
بلافاصله
از HTTP/2
پشتیبانی
میکند.
درخواستهای
HTTPS همچنان HTTP/2
را به روش
استاندارد
و با
نسخههای
پروتکل
مذاکرهشده
در مصافحه TLS
انجام
میدهند.
از نسخه 8.10.0 به بعد، اگر این گزینه برای یک درخواست HTTPS تنظیم شود، نسخه پروتکل لایه کاربرد (ALPN) ارائهشده به سرور فقط HTTP/2 خواهد بود. پیش از آن، هر دو نسخه HTTP/1.1 و HTTP/2 ارائه میشدند.
ارائه چندباره --http2-prior-knowledge اثر اضافهای ندارد. با --no-http2-prior-knowledge دوباره آن را غیرفعال کنید.
مثال:
curl --http2-prior-knowledge https://example.com
برای کارکردن --http2-prior-knowledge، لازم است که libcurl زیرین با پشتیبانی از HTTP/2 ساخته شده باشد. این گزینه با --http1.1، --http1.0، --http2 و --http3 مانعةالجمع است. همچنین --http2 و --http3 را ببینید.
- --http3
- (HTTP) تلاش برای
استفاده از
HTTP/3 با میزبان
موجود در URL،
اما بازگشت
به
نسخههای
قبلی HTTP در
صورتی که
برقراری
اتصال HTTP/3
ناموفق
باشد یا به
کندی انجام
شود. HTTP/3 فقط
برای URLهای HTTPS
در دسترس
است و نه
برای URLهای HTTP.
این گزینه به کاربر امکان میدهد در صورتی که میدانید یا حدس میزنید هدف روی میزبان و درگاه دادهشده با HTTP/3 ارتباط برقرار میکند، از بهکارگیری روش Alt-Svc برای ارتقا به HTTP/3 اجتناب کند.
هنگامی که از curl خواسته میشود از HTTP/3 استفاده کند، تلاشی جداگانه را با اندکی تأخیر برای استفاده از نسخههای قدیمیتر HTTP انجام میدهد؛ بنابراین اگر انتقال HTTP/3 با شکست مواجه شود یا کند باشد، curl همچنان تلاش میکند با یک نسخه قدیمیتر HTTP پیش برود. این بازگشت به عقب، مذاکره معمول میان HTTP/1 و HTTP/2 را انجام میدهد.
برای قابلیتی مشابه بدون بازگشت به عقب، از --http3-only استفاده کنید.
curl نمیتواند HTTP/3 را روی هیچ پروکسیای انجام دهد.
ارائه چندباره --http3 اثر اضافهای ندارد.
مثال:
curl --http3 https://example.com
برای کارکردن --http3، لازم است که libcurl زیرین با پشتیبانی از HTTP/3 ساخته شده باشد. این گزینه با --http1.1، --http1.0، --http2، --http2-prior-knowledge و --http3-only مانعةالجمع است. اضافهشده در 7.66.0. همچنین --http1.1 و --http2 را ببینید.
- --http3-only
- (HTTP) به curl دستور
میدهد تا
برای
میزبان
موجود در URL
از HTTP/3 بدون
هیچ
بازگشتی به
نسخههای
قبلی HTTP
استفاده
کند. HTTP/3 تنها
برای URLهای HTTPS
قابل
استفاده
است و نه
برای URLهای HTTP.
برای HTTP، این
گزینه باعث
بروز خطا
میشود.
این گزینه به کاربر امکان میدهد در صورتی که میدانید هدف روی میزبان و درگاه دادهشده با HTTP/3 ارتباط برقرار میکند، از بهکارگیری روش Alt-Svc برای ارتقا به HTTP/3 اجتناب کند.
این گزینه باعث میشود در صورتی که اتصال QUIC برقرار نشود curl با شکست مواجه گردد؛ این گزینه به خودی خود هیچ نسخه دیگر HTTP را امتحان نمیکند. برای قابلیتی مشابه همراه با بازگشت به عقب، از --http3 استفاده کنید.
ارائه چندباره --http3-only اثر اضافهای ندارد.
مثال:
curl --http3-only https://example.com
برای کارکردن --http3-only، لازم است که libcurl زیرین با پشتیبانی از HTTP/3 ساخته شده باشد. این گزینه با --http1.1، --http1.0، --http2، --http2-prior-knowledge و --http3 مانعةالجمع است. اضافهشده در 7.88.0. همچنین --http1.1، --http2 و --http3 را ببینید.
- --httpsig-algo <algorithm>
- (HTTP) **هشدار**:
این گزینه
آزمایشی
است. در
محیط
عملیاتی
استفاده
نکنید.
امضای درخواستهای خروجی HTTP با استفاده از امضاهای پیام HTTP طبق RFC 9421.
این گزینه مشخص میکند که از کدام الگوریتم امضا استفاده شود. مقادیر پشتیبانیشده عبارتند از ed25519 و hmac-sha256. در صورت مشخص نشدن، ed25519 استفاده میشود. هر مقدار دیگری باعث خروج curl با خطا میشود.
امضاهای پیام HTTP زمانی فعال میشوند که هر یک از --httpsig-algo، --httpsig-key، --httpsig-keyid یا --httpsig-headers داده شده باشد. در صورت فعال بودن، --httpsig-key و --httpsig-keyid الزامی هستند. بدون هیچیک از این گزینهها هیچ امضایی انجام نمیشود.
بهطور پیشفرض، مؤلفههای امضاشده عبارتند از "method"، "authority"، "path" و "query" (هنگامی که رشته پرسمان وجود داشته باشد). برای جایگزینی مجموعه مؤلفههای گنجاندهشده در امضا از --httpsig-headers استفاده کنید.
اگر --httpsig-algo چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --httpsig-key key.hex --httpsig-keyid "my-key" https://example.com curl --httpsig-algo hmac-sha256 --httpsig-key secret.hex --httpsig-keyid "shared" https://example.com
در 8.22.0 اضافه شد. همچنین ببینید --httpsig-key، --httpsig-keyid و --httpsig-headers.
- --httpsig-headers <components>
- (HTTP) **هشدار**:
این گزینه
آزمایشی
است. در
محیط
عملیاتی
استفاده
نکنید.
فهرستی جداشده با فاصله از مؤلفهها برای گنجاندن در امضای پیام HTTP طبق RFC 9421. مؤلفههای اشتقاقیافته به صورت نامهای خالی آورده میشوند: "method"، "authority"، "path" و "query". فیلدهای سرایند HTTP همراه با یک دونقطه در انتها مشخص میشوند، برای مثال "content-type:" و "content-digest:".
در صورت مشخص نشدن، مجموعه پیشفرض عبارت است از "method authority path" (بهعلاوه "query" هنگامی که رشته پرسمان در URL وجود داشته باشد).
- امضای سرایندهای درخواست
- مؤلفههای
سرایند فقط
از
گزینههای
"-H" / "--header"
گرفته
میشوند.
سرایندهایی
که curl بهطور
پیشفرض
اضافه
میکند
(مانند "User-Agent")
امضا
نمیشوند
مگر اینکه
آنها را
صراحتاً
تنظیم
کنید، برای
مثال:
curl --httpsig-algo ed25519 \ --httpsig-key k.hex \ --httpsig-keyid mykey \ -H "User-Agent: MyApp/1.0" \ --httpsig-headers \ "method authority path user-agent:" \ $URL
هر مؤلفه تنها یک بار میتواند ظاهر شود. شناسههای تکراری در "--httpsig-headers" باعث خروج curl با خطا میشوند.
-
اگر --httpsig-headers چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --httpsig-algo ed25519 --httpsig-key key.hex --httpsig-keyid "my-key" --httpsig-headers "method authority content-type:" https://example.com
در 8.22.0 اضافه شد. همچنین ببینید --httpsig-algo، --httpsig-key و --httpsig-keyid.
- --httpsig-key <key/file>
- (HTTP) **هشدار**:
این گزینه
آزمایشی
است. در
محیط
عملیاتی
استفاده
نکنید.
کلید مورد استفاده برای امضاهای پیام HTTP طبق RFC 9421. آن را همانگونه که هست یا به صورت "@filename" ارائه دهید. اگر آرگومان با یک "@" شروع شود، باقی آن به عنوان نام پرونده برای کلید در نظر گرفته میشود.
کلید به صورت دنبالهای از ارقام هگزادسیمال در یک خط قالببندی میشود. برای ed25519، این همان seed خصوصی 32 بایتی (64 نویسه هگزادسیمال) است. برای hmac-sha256، این همان راز مشترک (shared secret) است. پروندههای PEM پشتیبانی نمیشوند.
- تولید کلیدهای Ed25519
- با OpenSSL 3:
openssl genpkey -algorithm ED25519 -out k.pem openssl pkey -in k.pem -outform RAW -out k.raw xxd -p -c 64 k.raw | tr -d '\n' > k.hex
از "@k.hex" با "--httpsig-key" استفاده کنید.
-
اگر --httpsig-key چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --httpsig-algo ed25519 --httpsig-key @key.hex --httpsig-keyid "my-key" https://example.com curl --httpsig-key 123a56fb72197633bc --httpsig-keyid "my-key" https://example.com
در 8.22.0 اضافه شد. همچنین ببینید --httpsig-algo و --httpsig-keyid.
- --httpsig-keyid <id>
- (HTTP) **هشدار**:
این گزینه
آزمایشی
است. در
محیط
عملیاتی از
آن استفاده
نکنید.
شناسه کلید برای قرار گرفتن در سرآیند "Signature-Input" هنگام استفاده از RFC 9421 HTTP Message Signatures. این مقدار به عنوان پارامتر "keyid" ظاهر میشود و به سرور اجازه میدهد کلید اعتبارسنجی صحیح را جستجو کند.
اگر --httpsig-keyid چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --httpsig-algo ed25519 --httpsig-key key.hex --httpsig-keyid "my-key" https://example.com
در نسخه 8.22.0 افزوده شد. همچنین ببینید --httpsig-algo و --httpsig-key.
- --ignore-content-length
- (FTP HTTP) برای HTTP،
سرآیند Content-Length
را نادیده
میگیرد.
این ویژگی
بهویژه
برای
سرورهایی
که با Apache 1.x کار
میکنند و
Content-Length نادرستی
را برای
پروندههای
بزرگتر از
2 گیگابایت
گزارش
میدهند،
مفید است.
برای FTP، این گزینه باعث میشود curl پیش از بارگیری پرونده، از اجرای دستور SIZE برای یافتن اندازه آن صرفنظر کند.
مشخص کردن چندباره --ignore-content-length تأثیر مضاعفی ندارد. با --no-ignore-content-length دوباره آن را غیرفعال کنید.
مثال:
curl --ignore-content-length https://example.com
همچنین ببینید --ftp-skip-pasv-ip.
- -k, --insecure
- (TLS SFTP SCP) بهطور
پیشفرض،
هر اتصال
امنی که curl
برقرار
میکند،
پیش از
انجام
انتقال از
نظر امن
بودن
اعتبارسنجی
میشود. این
گزینه باعث
میشود curl
مرحله
اعتبارسنجی
را نادیده
گرفته و
بدون بررسی
ادامه دهد.
هنگامی که از این گزینه برای پروتکلهای مبتنی بر TLS استفاده نشود، curl پیش از ادامه، گواهی TLS سرور را اعتبارسنجی میکند: این که گواهی حاوی نام درستی باشد که با نام میزبان ارائهشده در URL مطابقت دارد و این که گواهی توسط یک گواهی CA موجود در مخزن گواهیها امضا شده باشد. برای جزئیات بیشتر به این منبع برخط مراجعه کنید: https://curl.se/docs/sslcerts.html
برای SFTP و SCP، این گزینه باعث میشود curl از اعتبارسنجی known_hosts صرفنظر کند. known_hosts پروندهای است که معمولاً در پوشه خانگی کاربر در زیرپوشه ".ssh" ذخیره میشود و شامل نام میزبانها و کلیدهای عمومی آنها است.
هشدار: استفاده از این گزینه باعث ناامن شدن انتقال میشود.
هنگامی که curl از پروتکلهای امن استفاده میکند، به پاسخها اعتماد کرده و برای نمونه اجازه میدهد اطلاعات HSTS و Alt-Svc ذخیره شده و پس از آن مورد استفاده قرار گیرند. استفاده از --insecure میتواند باعث شود curl به چنین اطلاعاتی از سوی سرورهای مخرب اعتماد کرده و از آنها استفاده کند.
مشخص کردن چندباره --insecure تأثیر مضاعفی ندارد. با --no-insecure دوباره آن را غیرفعال کنید.
مثال:
curl --insecure https://example.com
همچنین ببینید --proxy-insecure، --cacert و --capath.
- --interface <name>
- انجام عملیات با استفاده از یک رابط مشخصشده. شما میتوانید نام رابط، نشانی IP یا نام میزبان را وارد کنید. اگر ترجیح میدهید دقیقتر مشخص کنید، میتوانید از نحو ویژه زیر استفاده کنید:
- if!<name>
- نام رابط. اگر نام ارائهشده با یک رابط موجود مطابقت نداشته باشد، curl با خطای 45 خارج میشود.
- host!<name>
- نشانی IP یا نام میزبان.
- ifhost!<interface>!<host>
- نام رابط و
نشانی IP یا
نام میزبان.
این نحو به libcurl
8.9.0 یا بالاتر
نیاز دارد.
اگر نام ارائهشده با یک رابط موجود مطابقت نداشته باشد، curl با خطای 45 خارج میشود.
- curl در Windows از
استفاده از
نامهای
رابط شبکه
برای این
گزینه
پشتیبانی
نمیکند.
در صورت ارائه نام میزبان، آن عملیات تحلیل نام حتی در صورت تنظیم بودن --doh-url از DNS-over-HTTPS استفاده نمیکند.
در لینوکس از این گزینه میتوان برای تعیین یک دستگاه VRF (Virtual Routing and Forwarding) استفاده کرد، اما در این صورت فایل اجرایی یا باید قابلیت CAP_NET_RAW را داشته باشد یا به عنوان کاربر root اجرا شود.
اگر --interface چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --interface eth0 https://example.com curl --interface "host!10.0.0.1" https://example.com curl --interface "if!enp3s0" https://example.com
همچنین ببینید --dns-interface.
- --ip-tos <string>
- تنظیم نوع
سرویس (TOS)
برای IPv4 یا
کلاس
ترافیک (Traffic Class)
برای IPv6.
مقادیر مجاز برای <string> میتواند یک مقدار عددی بین 1 و 255 یا یکی از موارد زیر باشد:
CS0, CS1, CS2, CS3, CS4, CS5, CS6, CS7, AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43, EF, VOICE-ADMIT, ECT1, ECT0, CE, LE, LOWCOST, LOWDELAY, THROUGHPUT, RELIABILITY, MINCOST
اگر --ip-tos چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ip-tos CS5 https://example.com
در 8.9.0 افزوده شد. همچنین --tcp-nodelay و --vlan-priority را ببینید.
- --ipfs-gateway <URL>
- (IPFS) مشخص
میکند که
از کدام
درگاه برای
URLهای IPFS و IPNS
استفاده
شود. در
صورت عدم
تعیین این
گزینه، curl
بررسی
میکند که
آیا متغیر
محیطی IPFS_GATEWAY
تنظیم شده
است، یا
پرونده
"~/.ipfs/gateway" حاوی URL
درگاه وجود
دارد یا
خیر.
اگر یک گره محلی IPFS را اجرا میکنید، این درگاه به طور پیشفرض تحت "http://localhost:8080" در دسترس است. یک URL نمونه کامل به این شکل خواهد بود:
curl --ipfs-gateway http://localhost:8080 \ ipfs://bafybeigagd5nmnn2iys2f3
درگاههای عمومی IPFS متعددی وجود دارند. برای نمونه ببینید: https://ipfs.github.io/public-gateway-checker
اگر تصمیم به استفاده از یک درگاه دوردست بگیرید، باید آگاه باشید که کاملاً به آن درگاه اعتماد میکنید. این موضوع ممکن است در درگاههای محلی که خودتان میزبانی میکنید بدون مشکل باشد. اما در درگاههای دوردست، ممکن است عوامل مخربی وجود داشته باشند که دادههایی مغایر با درخواست شما را بازگردانند، درخواست را بازرسی کنند یا حتی در آن مداخله نمایند. هنگام استفاده از curl ممکن است متوجه این موضوع نشوید. یک راهکار کاهش خطر میتواند استفاده از یک درگاه "trustless" باشد. این بدان معناست که شما دادهها را به صورت محلی اعتبارسنجی میکنید. برای اطلاعات بیشتر در مورد trusted در برابر trustless، به صفحه مستندات مراجعه کنید: https://docs.ipfs.tech/reference/http/gateway/#trusted-vs-trustless
اگر --ipfs-gateway چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ipfs-gateway https://example.com ipfs://
در 8.4.0 افزوده شد. همچنین --help و --manual را ببینید.
- -4, --ipv4
- هنگام
تحلیل
نامهای
میزبان،
فقط
نشانیهای
IPv4 را
درخواست
میکند و
برای نمونه
هیچ نشانی IPv6
را درخواست
نمیکند.
مشخص کردن چندباره --ipv4 هیچ اثر اضافهای ندارد.
مثال:
curl --ipv4 https://example.com
این گزینه با --ipv6 مانعةالجمع است. همچنین --http1.1 و --http2 را ببینید.
- -6, --ipv6
- هنگام
تحلیل
نامهای
میزبان،
فقط
نشانیهای
IPv6 را
درخواست
میکند و
برای نمونه
هیچ نشانی IPv4
را درخواست
نمیکند.
تحلیلگر نام شما (resolver) ممکن است همچنان به یک درخواست تحلیل فقط-IPv6 با بازگرداندن نشانیهای IPv6 که به دلایل سازگاری حاوی نشانیهای IPv4 «نگاشتشده» ("mapped") هستند، پاسخ دهد. macOS به انجام این کار شناخته شده است.
مشخص کردن چندباره --ipv6 هیچ اثر اضافهای ندارد.
مثال:
curl --ipv6 https://example.com
این گزینه با --ipv4 مانعةالجمع است. همچنین --http1.1 و --http2 را ببینید.
- --json <data>
- (HTTP) ارسال
دادههای JSON
مشخصشده
در یک
درخواست POST
به سرور HTTP.
گزینه --json به
عنوان یک
میانبر
برای ارسال
این سه
گزینه عمل
میکند:
--data-binary [arg] --header "Content-Type: application/json" --header "Accept: application/json"
هیچ اعتبارسنجیای مبنی بر اینکه دادههای ارائهشده واقعاً JSON هستند یا نحو آن صحیح است، صورت نمیگیرد.
اگر داده را با حرف @ آغاز کنید، ادامه آن باید نام یک پرونده برای خواندن داده از آن باشد، یا یک خط تیره منفرد (-) در صورتی که بخواهید curl داده را از stdin بخواند. بنابراین ارسال داده از پروندهای به نام 'foobar' با --json @foobar انجام میشود و برای خواندن داده از stdin در عوض، از --json @- استفاده کنید.
اگر از این گزینه بیش از یک بار در همان خط فرمان استفاده شود، بخشهای داده اضافی پیش از ارسال به موارد قبلی متصل میشوند.
سرآیندهایی که این گزینه تنظیم میکند را میتوان طبق معمول با --header بازنویسی کرد.
--json میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl --json '{ "drink": "coffee" }' https://example.com curl --json '{ "drink":' --json ' "coffee" }' https://example.com curl --json @prepared https://example.com curl --json @- https://example.com < json.txtاین گزینه با --form، --head و --upload-file مانعةالجمع است. در 7.82.0 افزوده شد. همچنین --data-binary و --data-raw را ببینید.
- -j, --junk-session-cookies
- (HTTP) هنگامی که
به curl گفته
میشود
کوکیها را
از یک
پرونده
مشخص
بخواند،
این گزینه
باعث
میشود که
تمام
کوکیهای
نشست دور
ریخته شوند.
این کار
اثری مشابه
شروع یک
نشست جدید
دارد.
مرورگرهای
معمولی نیز
هنگام بسته
شدن،
کوکیهای
نشست را دور
میاندازند.
کوکیهای نشست، کوکیهایی بدون زمان انقضای مشخص هستند. آنها طوری طراحی شدهاند که تنها برای «یک نشست» باقی بمانند.
ارائه چندباره --junk-session-cookies اثر اضافهای ندارد. آن را دوباره با --no-junk-session-cookies غیرفعال کنید.
مثال:
curl --junk-session-cookies -b cookies.txt https://example.com
همچنین ببینید: --cookie و --cookie-jar.
- --keepalive-cnt <integer>
- حداکثر
تعداد
کاوشهای keepalive
را تعیین
میکند که TCP
باید پیش از
قطع کردن
اتصال
ارسال کند
اما پاسخی
دریافت
نکند. این
گزینه
معمولاً در
ترکیب با
--keepalive-time
استفاده
میشود.
این گزینه در Linux، *BSD/macOS، Windows >=10.0.16299، Solaris 11.4 و نسخههای جدید AIX، HP-UX و موارد دیگر پشتیبانی میشود. این گزینه در صورت استفاده از --no-keepalive هیچ اثری ندارد.
در صورت تعیین نشدن، مقدار پیشفرض این گزینه 9 است.
اگر --keepalive-cnt چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --keepalive-cnt 3 https://example.com
اضافهشده در 8.9.0. همچنین ببینید: --keepalive-time و --no-keepalive.
- --keepalive-time <seconds>
- مدت زمانی
را که یک
اتصال باید
پیش از
ارسال
کاوشهای keepalive
غیرفعال
بماند و
همچنین
فاصله
زمانی میان
هر یک از
کاوشهای keepalive
را تنظیم
میکند. این
گزینه در
حال حاضر
روی
سیستمعاملهایی
که
گزینههای
سوکت "TCP_KEEPIDLE" و
"TCP_KEEPINTVL" را
ارائه
میدهند
(یعنی Linux، *BSD/macOS،
Windows، Solaris و
نسخههای
اخیر AIX، HP-UX و
بیشتر) موثر
است. قابلیت
Keepalive توسط
پشته TCP برای
شناسایی
شبکههای
قطعشده در
اتصالات
غیرفعال
استفاده
میشود.
تعداد
کاوشهای
بیپاسخ keepalive
پیش از
اعلام قطعی
اتصال، به
سیستمعامل
بستگی دارد
و معمولاً 8
(*BSD/macOS/AIX)، 9 (Linux/AIX) یا 5/10 (Windows)
است، و این
عدد را
میتوان با
تعیین
گزینه "keepalive-cnt"
در curl تغییر
داد. توجه
داشته
باشید که
این گزینه
در صورت
استفاده از
--no-keepalive هیچ
اثری ندارد.
در صورت تعیین نشدن، مقدار پیشفرض این گزینه 60 ثانیه است.
اگر --keepalive-time چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --keepalive-time 20 https://example.com
همچنین ببینید: --no-keepalive، --keepalive-cnt و --max-time.
- --key <key>
- (TLS SCP SFTP) نام
پرونده
کلید خصوصی.
به شما
اجازه
میدهد
کلید خصوصی
خود را در
این پرونده
جداگانه
ارائه دهید.
برای SSH، در
صورت مشخص
نشدن، curl
نامزدهای
زیر را به
ترتیب
امتحان
میکند:
"~/.ssh/id_rsa"، "~/.ssh/id_dsa"،
"./id_rsa"، "./id_dsa".
اگر curl با کتابخانه OpenSSL کامپایل شده باشد و موتور pkcs11 یا ارائهدهنده pkcs11 در دسترس باشد، میتوان از یک PKCS#11 URI (RFC 7512) برای تعیین یک کلید خصوصی مستقر در یک دستگاه PKCS#11 استفاده کرد. رشتهای که با "pkcs11:" آغاز شود به عنوان یک PKCS#11 URI تفسیر میشود. اگر یک PKCS#11 URI ارائه شود، در صورت تعیین نشدن، گزینه --engine روی "pkcs11" تنظیم میشود و در صورت تعیین نشدن، گزینه --key-type روی "ENG" یا "PROV" تنظیم میشود (بسته به نسخه OpenSSL).
اگر curl با Schannel کامپایل شده باشد، این گزینه برای پروتکلهای TLS (HTTPS و غیره) نادیده گرفته میشود. آن بکاند انتظار دارد که کلید خصوصی از قبل در keychain یا پرونده PKCS#12 حاوی گواهی موجود باشد.
اگر --key چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --cert certificate --key here https://example.com
همچنین ببینید: --key-type و --cert.
- --key-type <type>
- (TLS) نوع
پرونده
کلید خصوصی.
نوع کلید
خصوصی
ارائهشده
با --key را
مشخص کنید.
فرمتهای
DER، PEM و ENG
پشتیبانی
میشوند. در
صورت مشخص
نشدن، PEM فرض
میشود.
اگر --key-type چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --key-type DER --key here https://example.com
همچنین ببینید: --key.
- --knownhosts <file>
- (SCP SFTP) هنگام
انجام
انتقالهای
SCP و SFTP، curl
بهطور
خودکار
پایگاهدادهای
حاوی
اطلاعات
شناسایی
تمام
میزبانهایی
را که
تاکنون با
آنها
استفاده
شده بررسی
میکند تا
تأیید کند
میزبانی که
به آن متصل
میشود
همان
میزبان
قبلی است.
کلیدهای
میزبان در
چنین
پروندهای
از
میزبانهای
شناختهشده
ذخیره
میشوند. curl
بهطور
پیشفرض از
~/.ssh/known_hosts در پوشه
خانگی
کاربر
استفاده
میکند.
این گزینه به کاربر امکان میدهد پرونده مشخصی را برای بررسی میزبان تعیین کند.
بررسی میزبانهای شناختهشده را میتوان با --insecure غیرفعال کرد، اما این کار انتقال را ناامن میکند و اکیداً توصیه نمیشود.
اگر --knownhosts چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --knownhosts filename --key here https://example.com
در 8.17.0 افزوده شد. همچنین ببینید --hostpubsha256، --hostpubmd5، --insecure و --key.
- --krb <level>
- (FTP) گزینه
منسوخشده
(افزوده شده
در 8.17.0). این
گزینه دیگر
هیچ
عملکردی
ندارد.
احراز هویت و استفاده از Kerberos را فعال میکند. سطح (level) باید وارد شود و باید یکی از "clear"، "safe"، "confidential" یا "private" باشد. اگر از سطحی استفاده کنید که یکی از این موارد نباشد، از "private" استفاده میشود.
اگر --krb چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --krb clear ftp://example.com
برای کارکرد --krb، لازم است که libcurl زیرین با پشتیبانی از Kerberos ساخته شده باشد. همچنین ببینید --delegation و --ssl.
- --libcurl <file>
- با افزودن
این گزینه
به هر خط
فرمان
معمولی curl،
کد منبع C
مبتنی بر libcurl
در پرونده
نوشته
میشود که
معادل همان
کاری است که
عملیات خط
فرمان شما
انجام
میدهد.
کد منبع خروجی باید به عنوان کد نمونه در نظر گرفته شود و آماده استفاده در محیط عملیاتی نیست. باید دوباره بررسی کنید که کد واقعاً همان کاری را که میخواهید انجام میدهد.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --libcurl چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --libcurl client.c https://example.com
همچنین ببینید --verbose.
- --limit-rate <speed>
- حداکثر نرخ
انتقالی را
که
میخواهید
curl استفاده
کند - هم
برای
بارگیریها
و هم
بارگذاریها
- مشخص کنید.
این قابلیت
زمانی مفید
است که
اتصال
محدودی
دارید و
میخواهید
انتقال شما
از تمام
پهنای
باندتان
استفاده
نکند، تا آن
را کندتر از
آنچه در غیر
این صورت
میبود کند.
سرعت دادهشده بر حسب بایت/ثانیه اندازهگیری میشود، مگر اینکه پسوندی به آن اضافه شود. افزودن 'k' یا 'K' عدد را به عنوان کیلوبایت محاسبه میکند، 'm' یا 'M' آن را به مگابایت تبدیل میکند و غیره. پسوندهای پشتیبانیشده (k، M، G، T، P) مبتنی بر 1024 هستند؛ برای مثال 1k برابر با 1024 است. مثالها: 200K، 3m و 1G.
منطق محدودسازی نرخ بر پایه میانگینگیری از سرعت انتقال کار میکند تا در طول یک دوره چند ثانیهای از آستانه تعیینشده فراتر نرود.
اگر از گزینه --speed-limit نیز استفاده کنید، آن گزینه اولویت دارد و ممکن است محدودسازی نرخ را اندکی مختل کند تا به حفظ کارکرد منطق speed-limit کمک نماید.
با شروع از curl 8.19.0، نرخ را میتوان با استفاده از یک کسر مانند "2.5M" برای دو و نیم مگابایت بر ثانیه مشخص کرد. این قابلیت صرفنظر از ترجیح locale شما، فقط با جداکننده نقطه (".") کار میکند.
اگر --limit-rate چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --limit-rate 123.45K https://example.com curl --limit-rate 1000 https://example.com curl --limit-rate 10M https://example.com curl --limit-rate 200K --max-time 60 https://example.com
همچنین ببینید --rate، --speed-limit و --speed-time.
- -l, --list-only
- (FTP POP3 SFTP FILE) هنگام
فهرستکردن
یک پوشه FTP،
نمای
فقط-نام را
اجباری
میکند. اگر
کاربر
بخواهد
محتوای یک
پوشه FTP را
بهصورت
ماشینی
تجزیه کند
میتواند
بسیار مفید
باشد، زیرا
نمای عادی
پوشه از
قالب یا
ظاهر
استانداردی
استفاده
نمیکند.
هنگامی که
به این صورت
استفاده
شود، این
گزینه باعث
میشود
دستور NLST به
جای LIST به
سرور ارسال
شود.
نکته: برخی از سرورهای FTP در پاسخ به NLST فقط پروندهها را فهرست میکنند؛ آنها زیرپوشهها و پیوندهای نمادین را شامل نمیشوند.
هنگام فهرستکردن یک پوشه SFTP، این سوییچ نمای فقط-نام را به صورت یک مورد در هر خط اجباری میکند. این قابلیت بهویژه زمانی مفید است که کاربر بخواهد محتوای یک پوشه SFTP را بهصورت ماشینی تجزیه کند، زیرا نمای عادی پوشه اطلاعات بیشتری نسبت به نام پروندهها ارائه میدهد.
هنگام دریافت یک ایمیل مشخص از POP3، این سوییچ اجرای دستور LIST را به جای RETR اجباری میکند. این قابلیت بهویژه زمانی مفید است که کاربر بخواهد بررسی کند آیا message-id خاصی روی سرور وجود دارد یا خیر و اندازه آن چقدر است.
برای FILE، این گزینه هنوز هیچ اثری ندارد زیرا پوشهها همیشه در این حالت فهرست میشوند.
نکته: در صورت ترکیب با --request، میتوان از این گزینه برای ارسال دستور UIDL به جای آن استفاده کرد، تا کاربر بتواند به جای message-id از شناسه یکتای ایمیل برای انجام درخواست استفاده کند.
مشخص کردن چندباره --list-only تأثیر اضافهای ندارد. دوباره با --no-list-only آن را غیرفعال کنید.
مثال:
curl --list-only ftp://example.com/dir
همچنین ببینید --quote و --request.
- --local-port <range>
- یک شماره
منفرد یا
بازهای (FROM-TO)
ترجیحی از
شماره
پورتهای
محلی را
برای
استفاده در
اتصال(ها)
تنظیم
میکند.
توجه داشته
باشید که
شماره
پورتها
ذاتاً
منبعی
محدود
هستند،
بنابراین
تنظیم این
بازه روی
مقداری بیش
از حد محدود
ممکن است
باعث شکست
غیرضروری
در برقراری
اتصال شود.
اگر --local-port چند بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --local-port 1000-3000 https://example.com
همچنین --globoff را ببینید.
- -L, --location
- (HTTP) اگر سرور
گزارش دهد
که صفحه
درخواستشده
به مکان
دیگری
منتقل شده
است (که با
سربرگ Location: و
یک کد پاسخ 3XX
مشخص
میشود)،
این گزینه
باعث
میشود curl
درخواست را
به مکان
جدید
دوباره
انجام دهد.
اگر همراه
با --show-headers یا --head
استفاده
شود،
سربرگهای
همه صفحات
درخواستشده
نمایش داده
میشوند.
هنگامی که احراز هویت در خط فرمان مشخص شده باشد (برای مثال --user یا --oauth2-bearer)، یا هنگام ارسال کوکی با "-H Cookie:"، curl اعتبارنامههای خود را فقط به میزبان اولیه ارسال میکند. اگر یک تغییر مسیر curl را به میزبان متفاوتی ببرد، اعتبارنامهها به آن منتقل نمیشوند. برای چگونگی تغییر این رفتار --location-trusted را ببینید. هنگامی که --netrc در ترکیب با این گزینه استفاده میشود، اعتبارنامهها برای میزبانهای دنبالشده نیز ممکن است از آن پرونده انتخاب شوند.
تعداد تغییر مسیرها برای دنبال کردن را با استفاده از گزینه --max-redirs محدود کنید.
هنگامی که curl یک تغییر مسیر را دنبال میکند و اگر درخواست یک POST باشد، چنانچه پاسخ HTTP برابر 301، 302 یا 303 بوده باشد، درخواست بعدی را با یک GET ارسال میکند. اگر کد پاسخ هر کد 3xx دیگری باشد، curl درخواست بعدی را با استفاده از همان متد بدون تغییر دوباره ارسال میکند.
میتوانید با استفاده از گزینههای اختصاصی برای این کار، به curl بگویید که پس از یک پاسخ 30x، درخواستهای POST را به GET تغییر ندهد: --post301، --post302 و --post303.
متد تنظیمشده با --request جایگزین متدی میشود که curl در غیر این صورت برای استفاده انتخاب میکرد.
پروتکلهایی را که تغییر مسیر مجاز به دنبال کردن آنها است، با --proto-redir محدود کنید.
مشخص کردن چندباره --location اثر اضافی ندارد. با --no-location دوباره آن را غیرفعال کنید.
مثال:
curl -L https://example.com
همچنین --resolve، --alt-svc، --follow، --proto-redir و --max-redirs را ببینید.
- --location-trusted
- (HTTP) به curl دستور
میدهد
تغییر
مسیرهای HTTP
را مانند
--location دنبال
کند، اما به
curl اجازه
میدهد
اعتبارنامهها
و سایر
اطلاعات
محرمانه را
به
میزبانهایی
غیر از
میزبان
اولیه نیز
ارسال کند.
اگر وبگاه شما را به وبگاهی هدایت کند که این دادههای حساس را به آن ارسال میکنید، این امر ممکن است منجر به یک رخنه امنیتی بشود یا نشود. میزبان دیگر به این معنی است که یک یا چند مورد از نام میزبان، طرحواره پروتکل یا شماره پورت تغییر کرده است.
این گزینه همچنین به curl اجازه میدهد کوکیهای طولانی را که صراحتاً با --header تنظیم شدهاند، ارسال کند.
مشخص کردن چندباره --location-trusted اثر اضافی ندارد. با --no-location-trusted دوباره آن را غیرفعال کنید.
مثالها:
curl --location-trusted -u user:password https://example.com curl --location-trusted -H "Cookie: session=abc" https://example.com
همچنین --user و --follow را ببینید.
- --login-options <options>
- (IMAP LDAP POP3 SMTP)
گزینههای
ورود را
برای
استفاده در
هنگام
احراز هویت
با سرور
مشخص کنید.
میتوانید از گزینههای ورود برای مشخص کردن گزینههای خاص پروتکل که ممکن است در حین احراز هویت استفاده شوند، بهره ببرید. در حال حاضر فقط IMAP، POP3 و SMTP از گزینههای ورود پشتیبانی میکنند. برای اطلاعات بیشتر درباره گزینههای ورود لطفاً به RFC 2384، RFC 5092 و پیشنویس IETF به نشانی https://datatracker.ietf.org/doc/html/draft-earhart-url-smtp-00 مراجعه کنید.
از نسخه 8.2.0، IMAP از گزینه ورود "AUTH=+LOGIN" پشتیبانی میکند. با این گزینه، curl از دستور ساده (غیر SASL) "LOGIN IMAP" استفاده میکند، حتی اگر سرور احراز هویت SASL را تبلیغ کند. در استفاده از این گزینه باید احتیاط کرد، زیرا گذرواژه شما را به صورت متن ساده روی شبکه ارسال میکند. اگر سرور IMAP دستور ساده "LOGIN" را غیرفعال کرده باشد (برای مثال برای جلوگیری از سرقت گذرواژه)، این گزینه کار نمیکند.
اگر --login-options چند بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --login-options 'AUTH=*' imap://example.com
همچنین --user را ببینید.
- --mail-auth <address>
- (SMTP) یک نشانی
واحد را
مشخص میکند.
از این
گزینه برای
تعیین
نشانی
احراز هویت
(هویت)
پیامی
استفاده
میشود که
ارسال شده و
در حال رله
شدن به
سروری دیگر
است.
اگر --mail-auth چندین بار مشخص شود، آخرین مقدار تنظیمشده بهکار میرود.
مثال:
curl --mail-auth user@example.com -T mail smtp://example.com/
همچنین ببینید: --mail-rcpt و --mail-from.
- --mail-from <address>
- (SMTP) یک نشانی
واحد را
مشخص میکند
که نامه
باید از آن
ارسال شود.
اگر --mail-from چندین بار مشخص شود، آخرین مقدار تنظیمشده بهکار میرود.
مثال:
curl --mail-from user@example.com -T mail smtp://example.com/
همچنین ببینید: --mail-rcpt و --mail-auth.
- --mail-rcpt <address>
- (SMTP) یک نشانی
رایانامه،
نام کاربری
یا نام
فهرست پستی
واحد را
مشخص میکند.
این گزینه
را برای
ارسال به
چندین
گیرنده،
چندین بار
تکرار کنید.
هنگام انجام اعتبارسنجی نشانی (دستور VRFY)، گیرنده باید بهصورت نام کاربری یا نام کاربری و دامنه مشخص شود (طبق بخش 3.5 از RFC 5321).
هنگام بسط دادن فهرست پستی (دستور EXPN)، گیرنده باید با استفاده از نام فهرست پستی مشخص شود، مانند "Friends" یا "London-Office".
گزینهٔ --mail-rcpt میتواند چندین بار در خط فرمان استفاده شود.
مثال:
curl --mail-rcpt user@example.net smtp://example.com
همچنین ببینید: --mail-rcpt-allowfails.
- --mail-rcpt-allowfails
- (SMTP) هنگام
ارسال داده
به چندین
گیرنده، curl
بهطور
پیشفرض در
صورتی که
حداقل یکی
از
گیرندگان
باعث شود
دستور RCPT TO
خطایی
برگرداند،
مکالمهٔ SMTP
را متوقف
میکند.
رفتار پیشفرض را میتوان با ارسال گزینهٔ خط فرمان --mail-rcpt-allowfails تغییر داد که باعث میشود curl از خطاها چشمپوشی کرده و با گیرندگان معتبر باقیمانده ادامه دهد.
اگر همهٔ گیرندگان باعث خطای RCPT TO شوند و این پرچم مشخص شده باشد، curl همچنان مکالمهٔ SMTP را متوقف کرده و خطای دریافتشده از آخرین دستور RCPT TO را بازمیگرداند.
مشخص کردن چندینبارهٔ --mail-rcpt-allowfails هیچ اثر اضافهای ندارد. آن را دوباره با --no-mail-rcpt-allowfails غیرفعال کنید.
مثال:
curl --mail-rcpt-allowfails --mail-rcpt dest@example.com smtp://example.com
افزودهشده در 7.69.0. همچنین ببینید: --mail-rcpt.
- -M, --manual
- راهنما.
نمایش متن
راهنمای
بسیار حجیم.
مثال:
curl --manual
همچنین ببینید: --verbose، --libcurl و --trace.
- --max-filesize <bytes>
- (FTP HTTP MQTT) هنگامی
که روی یک
مقدار
غیرصفر
تنظیم شود،
حداکثر
اندازه (به
بایت) یک
پرونده را
برای
بارگیری
مشخص میکند.
اگر
پروندهٔ
درخواستشده
بزرگتر از
این مقدار
باشد،
انتقال
آغاز
نمیشود و curl
با کد خروج 63
بازمیگردد.
تنظیم مقدار بیشینه روی صفر این محدودیت را غیرفعال میکند.
میتوان از پسوند یکحرفی واحد استفاده کرد. افزودن 'k' یا 'K' عدد را بهعنوان کیلوبایت، 'm' یا 'M' آن را به مگابایت و غیره محاسبه میکند. پسوندهای پشتیبانیشده (k, M, G, T, P) بر پایهٔ 1024 هستند. مثالها: 200K، 3m و 1G.
NOTE: پیش از curl 8.4.0، هنگامی که اندازهٔ پرونده پیش از بارگیری مشخص نبود، این گزینه برای چنین پروندههایی هیچ اثری نداشت، حتی اگر در نهایت انتقال پرونده بزرگتر از این حد تعیینشده میشد.
از curl 8.4.0 به بعد، این گزینه در صورتی که در حین انتقال به این آستانه برسد، انتقال را متوقف میکند.
از curl 8.19.0 به بعد، اندازهٔ بیشینه میتواند با استفاده از یک کسر مشخص شود، مانند "2.5M" برای دو و نیم مگابایت. این قابلیت تنها با جداکنندهٔ نقطه (".") کار میکند، صرفنظر از آنچه محلیسازی (locale) شما ترجیح میدهد.
از 8.20.0 به بعد، این گزینه همچنین انتقالهای در حال انجامی را که بهدلیل فشردهگشایی خودکار با استفاده از --compressed به این آستانه برسند، متوقف میکند.
اگر --max-filesize چندین بار مشخص شود، آخرین مقدار تنظیمشده بهکار میرود.
مثالها:
curl --max-filesize 100K https://example.com curl --max-filesize 2.6M https://example.com
همچنین ببینید: --limit-rate.
- --max-redirs <num>
- (HTTP) حداکثر
تعداد
تغییرمسیرهایی
که باید
دنبال شوند
را تعیین
میکند.
هنگامی که
--location یا --follow
استفاده
میشوند،
این گزینه
مانع از
دنبال کردن
بیش از حد
تغییرمسیرها
توسط curl
میشود. به
طور پیشفرض
این
محدودیت
روی 50
تغییرمسیر
تنظیم شده
است. این
گزینه را
روی -1 تنظیم
کنید تا
نامحدود
شود.
اگر --max-redirs چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --max-redirs 3 --location https://example.com
همچنین ببینید --location و --follow.
- -m, --max-time <seconds>
- حداکثر
زمان بر حسب
ثانیه را
تعیین
میکند که به
هر انتقال
اجازه
میدهید طول
بکشد. از
معلق ماندن
کارهای
دستهای
شما به مدت
چندین ساعت
به دلیل
کندی شبکه
یا قطع شدن
پیوندها
جلوگیری
میکند. این
گزینه
مقادیر
اعشاری را
میپذیرد.
اگر تلاش مجدد برای انتقال را فعال کنید (--retry)، شمارنده حداکثر زمان با هر بار تلاش مجدد برای انتقال بازنشانی میشود. میتوانید از --retry-max-time برای محدود کردن زمان تلاش مجدد استفاده کنید.
مقدار اعشاری باید با استفاده از نقطه (.) به عنوان جداکننده اعشار ارائه شود - نه نگارش محلی، حتی اگر از جداکننده دیگری استفاده کند.
اگر --max-time چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --max-time 10 https://example.com curl --max-time 2.92 https://example.com
همچنین ببینید --connect-timeout و --retry-max-time.
- --metalink
- این گزینه
قبلاً برای
مشخص کردن
یک منبع Metalink
استفاده
میشد.
پشتیبانی
از Metalink به
دلایل
امنیتی در curl
غیرفعال
شده است
(اضافهشده
در 7.78.0).
اگر --metalink چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --metalink file https://example.com
همچنین ببینید --parallel.
- --mptcp
- استفاده از
Multipath TCP (MPTCP) را برای
اتصالات
فعال میکند.
پروتکل MPTCP یک
افزونه
برای TCP
استاندارد
است که
امکان
چندین
جریان TCP را
در مسیرهای
مختلف شبکه
بین همان
مبدأ و مقصد
فراهم
میکند. این
قابلیت
میتواند با
استفاده
همزمان از
چندین
مسیر،
پهنای باند
را افزایش
داده و
پایداری را
بهبود بخشد.
پروتکل MPTCP در شبکههایی که چندین مسیر بین کلاینتها و سرورها وجود دارد سودمند است؛ مانند شبکههای تلفن همراه که در آن دستگاه ممکن است بین WiFi و داده تلفن همراه جابهجا شود، یا در شبکههای سیمی با چندین ارائهدهنده خدمات اینترنتی.
این گزینه در حال حاضر فقط روی لینوکس از هسته 5.6 به بعد پشتیبانی میشود. تنها اتصالات TCP تغییر مییابند، بنابراین این گزینه بر اتصالات HTTP/3 (QUIC) یا UDP تأثیری نمیگذارد.
سروری که curl به آن متصل میشود نیز باید از MPTCP پشتیبانی کند. در غیر این صورت، اتصال بدون مشکل به TCP بازمیگردد.
مشخص کردن چندباره --mptcp هیچ اثر اضافهای ندارد. آن را دوباره با --no-mptcp غیرفعال کنید.
مثال:
curl --mptcp https://example.com
اضافهشده در 8.9.0. همچنین ببینید --tcp-fastopen.
- --negotiate
- (HTTP) احراز
هویت Negotiate (SPNEGO) را
فعال میکند.
این گزینه به کتابخانهای نیاز دارد که با پشتیبانی از GSS-API یا SSPI ساخته شده باشد. از --version استفاده کنید تا ببینید آیا curl شما از GSS-API/SSPI یا SPNEGO پشتیبانی میکند یا خیر.
هنگام استفاده از این گزینه، باید یک گزینه ساختگی --user نیز برای فعالسازی صحیح کد احراز هویت ارائه دهید. ارسال یک '-u :' کافی است، زیرا نام کاربری و گذرواژه حاصل از گزینه --user در واقع استفاده نمیشوند.
مشخص کردن چندباره --negotiate هیچ اثر اضافهای ندارد. آن را دوباره با --no-negotiate غیرفعال کنید.
مثال:
curl --negotiate -u : https://example.com
همچنین ببینید --basic، --ntlm، --anyauth و --proxy-negotiate.
- -n, --netrc
- باعث
میشود curl
پروندهٔ .netrc
را در
دایرکتوری
خانگی
کاربر برای
نام ورود و
گذرواژه
بررسی کند.
این مورد
معمولاً
برای FTP در
یونیکس
استفاده
میشود. در
صورت
استفاده با
HTTP، ابزار curl
احراز هویت
کاربر را
فعال
میکند.
برای
جزئیات
مربوط به
قالب
پرونده، netrc(5)
و ftp(1) را
ببینید. اگر
آن پرونده
مجوزهای
دسترسی
مناسب را
نداشته
باشد (نباید
برای
دیگران یا
گروه قابل
خواندن
باشد)، curl
خطایی
گزارش
نمیکند. از
متغیر
محیطی "HOME"
برای یافتن
دایرکتوری
خانگی
استفاده
میشود. اگر
متغیر
محیطی "NETRC"
تنظیم شده
باشد، آن
نام پرونده
به عنوان
پروندهٔ netrc
استفاده
میشود.
(اضافهشده
در 8.16.0)
اگر از --netrc-file استفاده شود، بر تمام روشهای دیگر تعیین پرونده اولویت دارد.
پروندهٔ netrc اعتبارنامهها را برای یک نام میزبان، مستقل از پروتکل و شماره درگاه مورد استفاده، فراهم میکند.
در ویندوز، دو نام پرونده در دایرکتوری خانگی بررسی میشوند: .netrc و _netrc، با ترجیح دادن اولی. نسخههای قدیمیتر در ویندوز فقط وجود _netrc را بررسی میکردند.
یک مثال سریع و ساده از نحوهٔ برپایی یک .netrc برای اینکه به curl اجازه دهد با نام کاربری "myself" و گذرواژهٔ "secret" به ماشین host.example.com دسترسی یابد، میتواند شبیه به این باشد:
machine host.example.com login myself password secret
ابزار curl همچنین از کلیدواژهٔ "default" پشتیبانی میکند. این مورد مشابه نام ماشین است، با این تفاوت که default با هر نامی تطابق دارد. تنها میتواند یک نشانهٔ "default" وجود داشته باشد و باید پس از تمام نشانههای machine قرار گیرد.
هنگام ارائهٔ نام کاربری در URL و استفاده از یک پروندهٔ .netrc، در صورتی که چنین مدخلی در پرونده پیش از یک مدخل عمومی ("generic") "machine" بدون تعیین "login" آمده باشد، curl به دنبال گذرواژهٔ آن کاربر خاص برای میزبان مشخصشده میگردد.
مشخص کردن چندبارهٔ --netrc اثر اضافهای ندارد. با --no-netrc آن را دوباره غیرفعال کنید.
مثال:
curl --netrc https://example.com
این گزینه با --netrc-file و --netrc-optional مانعةالجمع است. همچنین --netrc-file، --config و --user را ببینید.
- --netrc-file <filename>
- پروندهٔ netrc
مورد
استفاده را
تنظیم
میکند.
مشابه --netrc،
با این
تفاوت که
مسیر را نیز
(مطلق یا
نسبی) ارائه
میدهید.
در صورت تعیین، از --netrc-optional پیروی میکند.
اگر --netrc-file چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --netrc-file netrc https://example.com
این گزینه با --netrc مانعةالجمع است. همچنین --netrc، --user و --config را ببینید.
- --netrc-optional
- مشابه --netrc،
اما این
گزینه
استفاده از
.netrc را
اختیاری
میکند و بر
خلاف
گزینهٔ --netrc،
آن را
اجباری
نمیسازد.
مشخص کردن چندبارهٔ --netrc-optional اثر اضافهای ندارد. با --no-netrc-optional آن را دوباره غیرفعال کنید.
مثال:
curl --netrc-optional https://example.com
این گزینه با --netrc مانعةالجمع است. همچنین --netrc-file را ببینید.
- -:, --next
- از یک
عملیات
مجزا برای URL
بعدی و
گزینههای
مرتبط با آن
استفاده
میکند. این
به شما
امکان
میدهد
چندین
درخواست URL
ارسال کنید
که هر کدام
گزینههای
مخصوص به
خود را
دارند؛
برای مثال،
مانند
نامهای
کاربری
متفاوت یا
درخواستهای
سفارشی
برای هر یک.
گزینهٔ --next تمام گزینههای محلی را بازنشانی میکند و تنها گزینههای سراسری مقادیر خود را برای عملیات پس از دستور --next حفظ میکنند. گزینههای سراسری شامل --verbose، --trace، --trace-ascii و --fail-early هستند.
برای مثال، میتوانید هر دو عمل GET و POST را در یک خط فرمان انجام دهید:
curl www1.example.com --next -d postthis www2.example.com
گزینهٔ --next میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl https://example.com --next -d postthis www2.example.com curl -I https://example.com --next https://example.net
همچنین --parallel و --config را ببینید.
- --no-alpn
- (HTTPS) افزونهٔ TLS
مربوط به ALPN
را غیرفعال
میکند. اگر libcurl
با یک
کتابخانهٔ
SSL که از ALPN
پشتیبانی
میکند
ساخته شده
باشد، ALPN
بهطور
پیشفرض
فعال است. ALPN
توسط libcurl
پشتیبانیکننده
از HTTP/2 برای
مذاکره بر
سر
پشتیبانی
از HTTP/2 با سرور
در طول
نشستهای https
استفاده
میشود.
توجه داشته باشید که این، نام گزینهٔ منفیشده است که مستند شده است. برای فعالسازی ALPN میتوانید از --alpn استفاده کنید.
ارائهٔ چندبارهٔ --no-alpn تأثیر اضافهای ندارد. دوباره آن را با --alpn غیرفعال کنید.
مثال:
curl --no-alpn https://example.com
برای کارکردن --no-alpn، لازم است که libcurl زیرین برای پشتیبانی از TLS ساخته شده باشد. همچنین --no-npn و --http2 را ببینید.
- -N, --no-buffer
- بافرسازی
جریان
خروجی را
غیرفعال
میکند. در
شرایط کاری
عادی، curl از
یک جریان
خروجی
بافرشدهٔ
استاندارد
استفاده
میکند که
باعث میشود
دادهها را
به صورت
تکهای
خروجی دهد،
نه لزوماً
دقیقاً
همان زمانی
که دادهها
میرسند.
استفاده از
این گزینه،
آن
بافرسازی
را غیرفعال
میکند.
توجه داشته باشید که این، نام گزینهٔ منفیشده است که مستند شده است. برای فعالسازی مجدد بافرسازی میتوانید از --buffer استفاده کنید.
ارائهٔ چندبارهٔ --no-buffer تأثیر اضافهای ندارد. دوباره آن را با --buffer غیرفعال کنید.
مثال:
curl --no-buffer https://example.com
همچنین --progress-bar را ببینید.
- --no-clobber
- هنگامی که
همراه با
گزینههای
--output، --remote-header-name،
--remote-name یا --remote-name-all
استفاده
شود، curl از
رونویسی
فایلهایی
که از قبل
وجود دارند
خودداری
میکند. در
عوض، یک
نقطه و یک
عدد به
انتهای نام
فایلی که
قرار است
ایجاد شود
اضافه
میشود، تا
حداکثر filename.100
که پس از آن
هیچ فایلی
ایجاد
نمیکند.
توجه داشته باشید که این، نام گزینهٔ منفیشده است که مستند شده است. بنابراین میتوانید حتی در صورت مشخص شدن --remote-header-name، از --clobber برای اجبار به رونویسی استفاده کنید.
گزینهٔ --continue-at نمیتواند همراه با --no-clobber استفاده شود.
ارائهٔ چندبارهٔ --no-clobber تأثیر اضافهای ندارد. دوباره آن را با --clobber غیرفعال کنید.
مثال:
curl --no-clobber --output local/dir/file https://example.com
در نسخهٔ 7.83.0 اضافه شد. همچنین --output و --remote-name را ببینید.
- --no-keepalive
- استفاده از
پیامهای keepalive
را در اتصال
TCP غیرفعال
میکند. در
غیر این
صورت، curl
آنها را
بهطور
پیشفرض
فعال میکند.
توجه داشته باشید که این، نام گزینهٔ منفیشده است که مستند شده است. بنابراین میتوانید از --keepalive برای اجبار به برقراری keepalive استفاده کنید.
ارائهٔ چندبارهٔ --no-keepalive تأثیر اضافهای ندارد. دوباره آن را با --keepalive غیرفعال کنید.
مثال:
curl --no-keepalive https://example.com
همچنین --keepalive-time و --keepalive-cnt را ببینید.
- --no-npn
- (HTTPS) ابزار curl
هرگز از NPN
استفاده
نمیکند،
این گزینه
هیچ اثری
ندارد (در
نسخهٔ 7.86.0
اضافه شد).
افزونهٔ TLS مربوط به NPN را غیرفعال میکند. اگر libcurl با یک کتابخانهٔ SSL که از NPN پشتیبانی میکند ساخته شده باشد، NPN بهطور پیشفرض فعال است. NPN توسط libcurl پشتیبانیکننده از HTTP/2 برای مذاکره بر سر پشتیبانی از HTTP/2 با سرور در طول نشستهای https استفاده میشود.
ارائهٔ چندبارهٔ --no-npn تأثیر اضافهای ندارد. دوباره آن را با --npn غیرفعال کنید.
مثال:
curl --no-npn https://example.com
برای کارکردن --no-npn، لازم است که libcurl زیرین برای پشتیبانی از TLS ساخته شده باشد. همچنین --no-alpn و --http2 را ببینید.
- --no-progress-meter
- گزینهای
برای
غیرفعال
کردن خروجی
نشانگر
پیشرفت
بدون
بیصدا
کردن یا اثر
گذاشتن بر
پیامهای
هشدار و
اطلاعاتی،
برخلاف
کاری که --silent
انجام
میدهد.
توجه داشته باشید که این نام نفیشدهٔ گزینه است که مستند شده است. بنابراین میتوانید از --progress-meter برای فعال کردن دوبارهٔ نشانگر پیشرفت استفاده کنید.
ارائهٔ چندبارهٔ --no-progress-meter اثر اضافهای ندارد. دوباره با --progress-meter غیرفعالش کنید.
مثال:
curl --no-progress-meter -o store https://example.com
در 7.67.0 اضافه شد. همچنین ببینید: --verbose و --silent.
- --no-sessionid
- (TLS) غیرفعال
کردن
استفادهٔ curl
از کش
شناسهٔ
نشست SSL.
بهطور
پیشفرض
همهٔ
انتقالها
با استفاده
از کش انجام
میشوند.
توجه داشته
باشید در
حالی که
تلاش برای
استفادهٔ
مجدد از
شناسههای
نشست SSL
نباید هرگز
مشکلی
ایجاد کند،
به نظر
میرسد
پیادهسازیهای
معیوبی از SSL
در عمل وجود
دارند که
ممکن است
برای
موفقیتآمیز
بودن
انتقال،
لازم باشد
این مورد را
غیرفعال
کنید.
توجه داشته باشید که این نام نفیشدهٔ گزینه است که مستند شده است. بنابراین میتوانید از --sessionid برای اجباری کردن کش شناسهٔ نشست استفاده کنید.
ارائهٔ چندبارهٔ --no-sessionid اثر اضافهای ندارد. دوباره با --sessionid غیرفعالش کنید.
مثال:
curl --no-sessionid https://example.com
همچنین ببینید: --insecure.
- --noproxy <no-proxy-list>
- فهرست
جداشده با
ویرگول از
میزبانهایی
که در صورت
تعیین
پروکسی،
نباید برای
آنها از
پروکسی
استفاده
شود. تنها
نویسهٔ عام
(wildcard) یک
نویسهٔ "*"
تکی است که
با همهٔ
میزبانها
مطابقت
دارد و
عملاً
پروکسی را
غیرفعال
میکند. هر
نام در این
فهرست، یا
با
دامنهای
که شامل نام
میزبان است
و یا با خود
نام میزبان
مطابقت
داده
میشود.
برای مثال،
"local.com" با "local.com"،
"local.com:80" و "www.local.com"
مطابقت
دارد، اما
با "www.notlocal.com"
تطابق
ندارد.
برای استفاده از نامهای میزبان بینالمللی در این فهرست، نسخهٔ punycode نام میزبان را اضافه کنید.
این گزینه متغیرهای محیطی که پروکسی را غیرفعال میکنند ("no_proxy" و "NO_PROXY") بازنویسی میکند. اگر متغیر محیطی وجود دارد که پروکسی را غیرفعال میکند، میتوانید فهرست بدون پروکسی را به "" تنظیم کنید تا آن را بازنویسی کند.
نشانیهای IP مشخصشده برای این گزینه را میتوان با نشانهگذاری CIDR ارائه کرد (اضافهشده در 7.86.0): یک اسلش الحاقی و عدد که تعداد بیتهای شبکه از نشانی را برای استفاده در مقایسه مشخص میکند. برای مثال "192.168.0.0/16" با تمام نشانیهایی که با "192.168" شروع میشوند مطابقت خواهد داشت.
اگر --noproxy چند بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --noproxy "www.example" https://example.com
همچنین ببینید: --proxy.
- --ntlm
- (HTTP) استفاده
از احراز
هویت NTLM. روش
احراز هویت
NTLM توسط
مایکروسافت
طراحی شد و
توسط
وبسرورهای
IIS استفاده
میشود. این
یک پروتکل
اختصاصی
است که توسط
افراد
باهوش
مهندسی
معکوس شد و
بر اساس
تلاشهای
آنها در curl
پیادهسازی
گردید. این
نوع رفتار
نباید
تأیید شود؛
شما باید
هرکسی را که
از NTLM
استفاده
میکند
تشویق کنید
تا در عوض
به یک روش
احراز هویت
عمومی و
مستند شده
مانند Digest
مهاجرت کند.
اگر میخواهید NTLM را برای احراز هویت پروکسی خود فعال کنید، از --proxy-ntlm استفاده نمایید.
ارائهٔ چندبارهٔ --ntlm اثر اضافهای ندارد. دوباره با --no-ntlm غیرفعالش کنید.
مثال:
curl --ntlm -u user:password https://example.com
برای کارکرد --ntlm، لازم است که libcurl زیرین به همراه پشتیبانی از TLS ساخته شده باشد. همچنین ببینید: --proxy-ntlm.
- --ntlm-wb
- (HTTP) گزینهٔ
منسوخشده
(اضافهشده
در 8.8.0).
NTLM را بسیار شبیه به شیوهٔ --ntlm فعال میکرد، اما احراز هویت را به یک پروندهٔ اجرایی جداگانه واگذار میکرد که در زمان نیاز اجرا میشد.
ارائهٔ چندبارهٔ --ntlm-wb اثر اضافهای ندارد.
مثال:
curl --ntlm-wb -u user:password https://example.com
همچنین ببینید: --ntlm و --proxy-ntlm.
- --oauth2-bearer <token>
- (IMAP LDAP POP3 SMTP HTTP) توکن
حامل (Bearer Token) را
برای احراز
هویت سرور OAUTH
2.0 مشخص
میکند.
توکن حامل
به همراه
نام کاربری
استفاده
میشود که
میتواند
به عنوان
بخشی از
گزینههای
--url یا --user
مشخص شود.
توکن حامل و نام کاربری مطابق با RFC 6750 قالببندی میشوند.
اگر --oauth2-bearer چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --oauth2-bearer "mF_9.B5f-4.1JqM" https://example.com
همچنین --basic، --ntlm و --digest را ببینید.
- --out-null
- تمام خروجی
پاسخ یک
انتقال را
در سکوت دور
میریزد.
این نگارش
کارآمدتر و
قابلحملتری
از دستور
زیر است:
curl https://host.example -o /dev/null
انتقال به طور کامل انجام میشود، تمام دادهها دریافت و بررسی میشوند، اما بایتها در هیچکجا نوشته نمیشوند.
گزینه --out-null با یک URL منفرد مرتبط است. هنگامی که از چندین URL در یک خط فرمان استفاده میکنید، برای هر URL یک بار از آن استفاده کنید.
مثال:
curl "https://example.com" --out-null
در نسخه 8.16.0 اضافه شد. همچنین --output، --remote-name، --remote-name-all و --remote-header-name را ببینید.
- -o, --output <file>
- خروجی را به
جای stdout در
پرونده
دادهشده
مینویسد.
اگر برای
دریافت
چندین سند
از تطبیق
الگو (globbing) در URL
استفاده
میکنید،
باید URL را
درون
نقلقول
قرار دهید و
میتوانید
از "#" به
همراه یک
عدد در نام
پرونده
استفاده
کنید. آن
متغیر با
متن تطبیق
الگوی فعلی
جایگزین
میشود.
مانند:
curl "http://{one,two}.example.com" -o "file_#1.txt"یا از چندین متغیر استفاده کنید مانند:
curl "http://{site,host}.host[1-5].example" -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 را برای ایجاد پویای دایرکتوریهای محلی ببینید. مشخص کردن خروجی به صورت '-' (یک خط تیره منفرد) خروجی را به stdout ارسال میکند.
برای جلوگیری از نمایش بدنه پاسخ، میتوانید خروجی را به /dev/null هدایت کنید:
curl example.com -o /dev/null
یا برای Windows:
curl example.com -o nul
یا برای روشی حتی کارآمدتر و قابلحملتر، از این دستور استفاده کنید:
curl example.com --out-null
نام پرونده را به صورت یک خط تیره منفی منفرد مشخص کنید تا خروجی به stdout اجبار شود و سازوکار داخلی curl در جلوگیری از خروجی باینری در ترمینال نادیده گرفته شود:
curl https://example.com/jpeg -o -
توجه داشته باشید که خروجی باینری ممکن است به دلیل فشرده بودن پاسخ باشد، که در این حالت ممکن است بخواهید از گزینه --compressed استفاده کنید.
از نسخه 8.21.0 در curl، میتوان بخشهای جداگانه تطبیق الگو (globbing) را نامگذاری کرد و با نامهایشان به آنها ارجاع داد. نام الفبایی-عددیِ حساس به بزرگ و کوچکی حروف پس از نویسه آغازین درون علامتهای زاویهدار (<>) قرار میگیرد. مثالها:
curl "https://fun.example/{<num>one,two}.jpg" -o "save-#<num>" curl "ftp://ftp.example/file[<range>1-100].txt" \ -o "save-#<range>.txt"ارجاع به یک glob نامگذاریشده که تنظیم نشده باشد، باعث بروز خطا میشود.
از نسخه 8.21.0 در curl، میتوانید هنگام استفاده از تطبیق الگو (globbing) در نام پرونده بارگذاری، با تنظیم نام glob و ارجاع به آن به همان روشی که به globهای نامگذاریشده در URL ارجاع میدهید، از بخشهایی از نام پرونده بارگذاری استفاده کنید. برای مثال، اگر سه پرونده را به یک URL ثابت HTTP بارگذاری میکنید و میخواهید پاسخهای متناظر را در پروندههای جداگانه ذخیره کنید:
curl -T 'file{<num>1,2,3}' \ https://upload.example/ -o 'response-#<num>'گزینه --output با یک URL منفرد مرتبط است. هنگامی که از چندین URL در یک خط فرمان استفاده میکنید، برای هر URL یک بار از آن استفاده کنید.
مثالها:
curl -o file https://example.com curl "http://{one,two}.example.com" -o "file_#1.txt" curl "http://{site,host}.host[1-5].example" -o "#1_#2" curl -o file https://example.com -o file2 https://example.netهمچنین --out-null، --remote-name، --remote-name-all، --remote-header-name و --compressed را ببینید.
- --output-dir <dir>
- دایرکتوری
محل ذخیرهٔ
پروندهها
را هنگام
استفاده از
--remote-name یا --output
مشخص
میکند.
دایرکتوری خروجی دادهشده برای همهٔ URLها و گزینههای خروجی در خط فرمان، تا پیش از نخستین --next استفاده میشود.
اگر دایرکتوری مقصد مشخصشده وجود نداشته باشد، عملیات با شکست مواجه میشود مگر اینکه از --create-dirs نیز استفاده شده باشد.
اگر --output-dir چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --output-dir "tmp" -O https://example.com
در 7.73.0 اضافه شد. همچنین ببینید --remote-name و --remote-header-name.
- -Z, --parallel
- باعث
میشود curl در
مقایسه با
شیوهٔ
ترتیبی
(سریال)
معمول،
همهٔ
انتقالها
را به صورت
موازی
انجام دهد.
انتقال
موازی بدان
معناست که curl
تا N انتقال
همزمان را
به طور
همزمان
اجرا
میکند و
اگر بیش از N
انتقال
برای
رسیدگی
وجود داشته
باشد، با
پایان
یافتن
انتقالهای
قبلی،
انتقالهای
جدید را
آغاز
میکند.
در انتقالهای موازی، خروجی نشانگر پیشرفت با زمان انجام انتقالهای ترتیبی متفاوت است، زیرا وضعیت چند انتقال را در یک خط نمایش میدهد.
حداکثر تعداد انتقالهای همزمان با --parallel-max تنظیم میشود و مقدار پیشفرض آن 50 است.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
مشخص کردن چندبارهٔ --parallel هیچ تأثیر اضافهای ندارد. با --no-parallel دوباره آن را غیرفعال کنید.
مثال:
curl --parallel https://example.com -o file1 https://example.com -o file2
در 7.66.0 اضافه شد. همچنین ببینید --next، --verbose، --parallel-max و --parallel-immediate.
- --parallel-immediate
- هنگام
انجام
انتقالهای
موازی، این
گزینه به curl
دستور
میدهد باز
کردن
اتصالات
موازی
بیشتر به
صورت
یکباره را
ترجیح دهد،
به جای آنکه
منتظر
بماند تا
ببیند آیا
انتقالهای
جدید
میتوانند
به صورت
جریانهای
چندبخشی (multiplexed)
روی اتصال
دیگری
اضافه شوند
یا خیر.
بهطور پیشفرض و بدون تنظیم این گزینه، curl ترجیح میدهد اندکی صبر کند و انتقالهای جدید را روی اتصالات موجود تسهیم (multiplex) کند. این کار تعداد اتصالات را به بهای خطر آغازِ کمی کندتر انتقال، پایین نگه میدارد.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
مشخص کردن چندبارهٔ --parallel-immediate هیچ تأثیر اضافهای ندارد. با --no-parallel-immediate دوباره آن را غیرفعال کنید.
مثال:
curl --parallel-immediate -Z https://example.com -o file1 https://example.com -o file2
در 7.68.0 اضافه شد. همچنین ببینید --parallel و --parallel-max.
- --parallel-max <num>
- هنگام
درخواست
برای انجام
انتقالهای
موازی با
استفاده از
--parallel، این
گزینه
حداکثر
تعداد
انتقالهایی
را که باید
به طور
همزمان
انجام شوند
کنترل
میکند.
مقدار پیشفرض 50 است. 65535 بزرگترین مقدار پشتیبانیشده است.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --parallel-max چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --parallel-max 100 -Z https://example.com ftp://example.com/
در 7.66.0 اضافه شد. همچنین ببینید --parallel و --parallel-max-host.
- --parallel-max-host <num>
- هنگام
درخواست
برای انجام
انتقالهای
موازی با
استفاده از
--parallel، این
گزینه
حداکثر
تعداد
اتصالات
همزمانی
را کنترل
میکند که curl
مجاز است با
یک هدف
یکسان
(پروتکل +
نام میزبان
+ شماره
پورت)
برقرار کند.
این محدودیت توسط libcurl اعمال شده و بهصورت «داخلی» در صف قرار میگیرد، به این معنی که انتقالهای در انتظار یک اتصال دردسترس، در نشانگر پیشرفت همچنان مانند انتقالهای آغازشده به نظر میرسند.
مقدار پیشفرض 0 (نامحدود) است. 65535 بزرگترین مقدار پشتیبانیشده است.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --parallel-max-host چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --parallel-max-host 5 -Z https://example.com ftp://example.com/
در 8.16.0 اضافه شد. همچنین ببینید --parallel و --parallel-max.
- --pass <phrase>
- (TLS SCP SFTP) عبارت
عبور برای
کلید خصوصی
استفادهشده
در SSH یا TLS.
اگر --pass چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --pass secret --key file https://example.com
همچنین --key و --user را ببینید.
- --path-as-is
- توالیهای
/../ یا /./ را در
مسیر URL
دادهشده
پردازش
نمیکند. در
حالت عادی curl
طبق
استانداردها
آنها را
فشرده یا
ادغام
میکند،
اما با
تنظیم این
گزینه به آن
میگویید
که این کار
را انجام
ندهد.
ارائه چندباره --path-as-is تأثیر اضافهای ندارد. با --no-path-as-is دوباره آن را غیرفعال کنید.
مثال:
curl --path-as-is https://example.com/../../etc/passwd
همچنین --request-target را ببینید.
- --pinnedpubkey <hashes>
- (TLS) استفاده
از فایل
کلید عمومی
مشخصشده
(یا هشها)
برای
اعتبارسنجی
همتا. این
میتواند
مسیری به یک
فایل باشد
که شامل یک
کلید عمومی
منفرد در
قالب PEM یا DER
است، یا هر
تعداد هش sha256
کدگذاریشده
با base64 که پیش
از آنها 'sha256//'
آمده و با ';'
از یکدیگر
جدا
شدهاند.
هنگام مذاکره برای یک اتصال TLS یا SSL، سرور گواهیای ارسال میکند که نشاندهنده هویت آن است. یک کلید عمومی از این گواهی استخراج میشود و اگر دقیقاً با کلید عمومی ارائهشده به این گزینه مطابقت نداشته باشد، curl پیش از ارسال یا دریافت هرگونه داده، اتصال را قطع میکند.
این گزینه مستقل از گزینه --insecure است. اگر از هر دو گزینه با هم استفاده کنید، همتا همچنان با استفاده از کلید عمومی اعتبارسنجی میشود.
پشتیبانی از PEM/DER:
OpenSSL و GnuTLS، wolfSSL، mbedTLS، Schannel
پشتیبانی از sha256:
OpenSSL، GnuTLS و wolfSSL، mbedTLS، Schannel
سایر backendهای SSL پشتیبانی نمیشوند.
اگر --pinnedpubkey چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
curl --pinnedpubkey keyfile https://example.com curl --pinnedpubkey 'sha256//ce118b51897f4452dc' https://example.com
همچنین --hostpubsha256 را ببینید.
- --post301
- (HTTP) از RFC 7231/6.4.2
پیروی کرده
و هنگام
دنبال کردن
یک تغییر
مسیر 301،
درخواستهای
POST را به
درخواستهای
GET تبدیل
نمیکند.
رفتار غیر-RFC
در
مرورگرهای
وب بسیار
فراگیر
است،
بنابراین curl
بهطور
پیشفرض
این تبدیل
را برای حفظ
سازگاری
انجام
میدهد. یک
سرور ممکن
است نیاز
داشته باشد
که یک POST پس از
چنین تغییر
مسیری
همچنان POST
باقی بماند.
این گزینه
تنها هنگام
استفاده از
--location معنادار
است.
مشخص کردن چندباره --post301 تأثیر اضافهای ندارد. با --no-post301 دوباره آن را غیرفعال کنید.
مثال:
curl --post301 --location -d "data" https://example.com
همچنین --post302، --post303 و --location را ببینید.
- --post302
- (HTTP) از RFC 7231/6.4.3
پیروی کرده
و هنگام
دنبال کردن
یک تغییر
مسیر 302،
درخواستهای
POST را به
درخواستهای
GET تبدیل
نمیکند.
رفتار غیر-RFC
در
مرورگرهای
وب بسیار
فراگیر
است،
بنابراین curl
بهطور
پیشفرض
این تبدیل
را برای حفظ
سازگاری
انجام
میدهد. یک
سرور ممکن
است نیاز
داشته باشد
که یک POST پس از
چنین تغییر
مسیری
همچنان POST
باقی بماند.
این گزینه
تنها هنگام
استفاده از
--location معنادار
است.
مشخص کردن چندباره --post302 تأثیر اضافهای ندارد. با --no-post302 دوباره آن را غیرفعال کنید.
مثال:
curl --post302 --location -d "data" https://example.com
همچنین --post301، --post303 و --location را ببینید.
- --post303
- (HTTP) نقض RFC 7231/6.4.4 و
عدم تبدیل
درخواستهای
POST به
درخواستهای
GET هنگام
دنبال کردن
تغییر مسیر
303. ممکن است
یک سرور
الزام کند
که یک POST پس از
تغییر مسیر
303 همچنان POST
باقی بماند.
این گزینه
تنها هنگام
استفاده از
--location معنا
دارد.
مشخص کردن چندباره --post303 هیچ اثر اضافهای ندارد. با --no-post303 دوباره آن را غیرفعال کنید.
مثال:
curl --post303 --location -d "data" https://example.com
همچنین ببینید --post302، --post301 و --location.
- --preproxy <[protocol://]host[:port]>
- قبل از
اتصال به یک
--proxy از نوع HTTP
یا HTTPS، از
پراکسی SOCKS
مشخصشده
استفاده
میکند. در
چنین حالتی
curl ابتدا به
پراکسی SOCKS
متصل
میشود و
سپس (از
طریق SOCKS) به
پراکسی HTTP یا
HTTPS وصل
میشود؛ از
این رو
پیشپراکسی
(pre proxy) نامیده
میشود.
رشته پیشپراکسی باید با یک پیشوند "protocol://" برای تعیین پروتکلهای پراکسی جایگزین مشخص شود. از "socks4://"، "socks4a://"، "socks5://" یا "socks5h://" برای درخواست نسخه مشخص SOCKS که باید استفاده شود، استفاده کنید. در صورت مشخص نشدن پروتکل، curl به طور پیشفرض از SOCKS4 استفاده میکند.
اگر شماره پورت در رشته پراکسی مشخص نشود، 1080 در نظر گرفته میشود.
نام کاربری و گذرواژهای که ممکن است در رشته پراکسی مشخص شده باشند، توسط curl رمزگشایی نشانی (URL decode) میشوند. این امکان به شما اجازه میدهد نویسههای خاص مانند @ را با استفاده از %40 یا دونقطه را با %3a ارسال کنید.
اگر --preproxy چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --preproxy socks5://proxy.example -x http://http.example https://example.com
همچنین ببینید --proxy و --socks5.
- -#, --progress-bar
- باعث
میشود curl
پیشرفت
انتقال را
به جای
سنجشگر
استاندارد
و حاوی
اطلاعات
بیشتر، به
صورت یک
نوار
پیشرفت
ساده نمایش
دهد.
این نوار پیشرفت یک خط از نویسههای '#' را در سرتاسر صفحه رسم میکند و در صورت مشخص بودن اندازه انتقال، درصد را نشان میدهد. برای انتقالهایی بدون اندازه مشخص، یک سفینه فضایی (-=o=-) وجود دارد که به جلو و عقب حرکت میکند، اما تنها در زمانی که داده در حال انتقال است، همراه با مجموعهای از نمادهای هش پرنده در بالای آن.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
مشخص کردن چندباره --progress-bar هیچ اثر اضافهای ندارد. با --no-progress-bar دوباره آن را غیرفعال کنید.
مثال:
curl -# -O https://example.com
همچنین ببینید --styled-output.
- --proto <protocols>
- پروتکلهای مجاز برای انتقال را محدود میکند. پروتکلها از چپ به راست ارزیابی میشوند، با ویرگول از هم جدا میشوند و هر یک نام یک پروتکل یا 'all' است که به صورت اختیاری میتواند یک پیشوند اصلاحکننده داشته باشد. اصلاحکنندههای موجود عبارتند از:
- +
- مجاز دانستن این پروتکل علاوه بر پروتکلهای مجاز فعلی (اگر هیچ اصلاحکنندهای استفاده نشود، این حالت پیشفرض است).
- -
- رد کردن این پروتکل، با حذف آن از فهرست پروتکلهای مجاز فعلی.
- =
- تنها مجاز دانستن این پروتکل (با نادیده گرفتن فهرست مجاز قبلی)، هرچند که در ادامه ممکن است توسط موارد بعدی در فهرست جداشده با ویرگول تغییر یابد.
- برای مثال:
--proto -ftps از
پروتکلهای
پیشفرض
استفاده
میکند،
اما ftps را
غیرفعال
میسازد
--proto -all,https,+http تنها http و https را فعال میکند
--proto =http,https نیز تنها http و https را فعال میکند
پروتکلهای ناشناخته و غیرفعال یک هشدار تولید میکنند. این قابلیت به اسکریپتها امکان میدهد تا بدون اتکا به تعبیه بودن پشتیبانی از آن پروتکل در curl برای جلوگیری از خطا، با اطمینان بر توانایی غیرفعال کردن پروتکلهای بالقوه خطرناک تکیه کنند.
این گزینه میتواند چندین بار استفاده شود، که در این حالت اثر آن همانند متصل کردن پروتکلها در یک مورد از این گزینه است.
اگر --proto چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proto =http,https,sftp https://example.com
همچنین ببینید --proto-redir و --proto-default.
- --proto-default <protocol>
- از protocol برای
هر URL
ارائهشدهای
که فاقد
طرحواره (scheme)
باشد
استفاده
میکند. نام
غیرحساس به
حروف بزرگ و
کوچک باید
بدون هیچ
پسوند "://"
مشخص شود.
یک پروتکل ناشناخته یا پشتیبانینشده باعث بروز خطای CURLE_UNSUPPORTED_PROTOCOL میشود.
این گزینه پروتکل پیشفرض پراکسی (http) را تغییر نمیدهد.
بدون تنظیم این گزینه، curl پروتکل را بر اساس نام میزبان حدس میزند؛ برای جزئیات --url را ببینید.
پروتکل پیشفرض نمیتواند روی "ipfs" یا "ipns" تنظیم شود. این طرحوارهها باید بهطور صریح در URL استفاده شوند.
اگر --proto-default چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proto-default https ftp.example.com
همچنین --proto و --proto-redir را ببینید.
- --proto-redir <protocols>
- پروتکلهای
مجاز در
تغییر
مسیرها (redirects)
را محدود
میکند.
پروتکلهای
ردشده توسط
--proto با این
گزینه لغو
(override)
نمیشوند.
برای نحوهٔ
نمایش
پروتکلها
--proto را
ببینید.
مثال، تنها مجاز کردن HTTP و HTTPS در تغییر مسیر:
curl --proto-redir -all,http,https --follow http://example.com
بهطور پیشفرض curl تنها به HTTP، HTTPS، FTP و FTPS در تغییر مسیرها اجازه میدهد. مشخص کردن all یا +all همهٔ پروتکلها را در تغییر مسیرها فعال میکند، که از نظر امنیتی مناسب نیست.
اگر --proto-redir چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proto-redir =http,https --follow https://example.com
همچنین --proto و --follow را ببینید.
- -x, --proxy <[protocol://]host[:port]>
- از پراکسی
مشخصشده
استفاده
میکند.
رشتهٔ پراکسی میتواند با یک پیشوند "protocol://" مشخص شود. اگر هیچ پروتکلی مشخص نشود یا http:// باشد، به عنوان یک پراکسی HTTP در نظر گرفته میشود. از "socks4://"، "socks4a://"، "socks5://" یا "socks5h://" برای درخواست استفاده از یک نسخهٔ خاص SOCKS استفاده کنید.
سوکتهای دامنهٔ یونیکس (Unix domain sockets) برای پراکسی socks پشتیبانی میشوند. بخش میزبان را localhost قرار دهید؛ مانند socks5h://localhost/path/to/socket.sock
پشتیبانی از پراکسی HTTPS با پیشوند پروتکل "https://" برای OpenSSL و GnuTLS کار میکند. همچنین برای mbedTLS، Rustls، Schannel و wolfSSL (اضافهشده در 7.87.0) نیز کار میکند.
طرحوارههای پروتکل پراکسی ناشناخته و پشتیبانینشده باعث بروز خطا میشوند.
اگر شماره درگاه (port) در رشتهٔ پراکسی مشخص نشده باشد، مقدار آن 1080 فرض میشود.
این گزینه متغیرهای محیطی موجود را که پراکسی مورد استفاده را تعیین میکنند بازنویسی (override) میکند. اگر متغیر محیطی وجود دارد که پراکسی را تنظیم کرده است، میتوانید پراکسی را روی "" تنظیم کنید تا آن را باطل نمایید.
تمام عملیاتی که از طریق یک پراکسی HTTP انجام میشوند، بهطور شفاف به HTTP تبدیل میگردند. این بدان معناست که ممکن است برخی از عملیات خاص پروتکل در دسترس نباشند. در صورتی که بتوانید از طریق پراکسی تونل ایجاد کنید، مانند استفاده از گزینهٔ --proxytunnel، اینگونه نخواهد بود.
نام کاربری و گذرواژهای که ممکن است در رشتهٔ پراکسی ارائه شوند، توسط curl رمزگشایی URL میشوند. این به شما امکان میدهد نویسههای خاص مانند @ را با استفاده از %40 یا دونقطه را با %3a ارسال کنید.
میزبان پراکسی میتواند به همان روش متغیرهای محیطی پراکسی مشخص شود، از جمله پیشوند پروتکل ("http://") و کاربر + گذرواژهٔ تعبیهشده.
هنگامی که از یک پراکسی استفاده میشود، حالت فعال FTP که با --ftp-port تنظیم میشود، قابل استفاده نیست.
انجام FTP از طریق یک پراکسی HTTP بدون --proxytunnel باعث میشود curl پروتکل HTTP را با یک URL مربوط به FTP از طریق پراکسی انجام دهد. برای چنین انتقالهایی، گزینههای متداول مخصوص FTP کار نمیکنند، از جمله --ssl-reqd و --ftp-ssl-control.
اگر --proxy چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy http://proxy.example https://example.com
همچنین --socks5 و --proxy-basic را ببینید.
- --proxy-anyauth
- بهطور
خودکار یک
روش احراز
هویت مناسب
را هنگام
برقراری
ارتباط با
پروکسی HTTP
مشخصشده
انتخاب
میکند. این
کار ممکن
است باعث یک
رفتوبرگشت
(round-trip) اضافه
برای
درخواست/پاسخ
شود.
مثال:
curl --proxy-anyauth --proxy-user user:passwd -x proxy https://example.com
همچنین ببینید --proxy، --proxy-basic و --proxy-digest.
- --proxy-basic
- هنگام
برقراری
ارتباط با
پروکسی
مشخصشده،
از احراز
هویت HTTP Basic
استفاده
میکند.
برای
فعالسازی
HTTP Basic با یک
میزبان راه
دور، از --basic
استفاده
کنید. روش Basic،
روش احراز
هویت
پیشفرض curl در
ارتباط با
پروکسیها
است.
ارائه چندباره --proxy-basic تأثیر اضافهای ندارد. آن را دوباره با --no-proxy-basic غیرفعال کنید.
مثال:
curl --proxy-basic --proxy-user user:passwd -x proxy https://example.com
همچنین ببینید --proxy، --proxy-anyauth و --proxy-digest.
- --proxy-ca-native
- (TLS) برای
اعتبارسنجی
گواهی
پروکسی HTTPS،
از مخزن
بومی CA
سیستمعامل
استفاده
میکند.
این گزینه مستقل از سایر مکانهای گواهی CA پروکسی HTTPS است که در زمان اجرا یا زمان ساخت تنظیم شدهاند. آن مکانها علاوه بر مخزن بومی CA جستجو میشوند.
معادل --ca-native است، اما در زمینه پروکسی HTTPS استفاده میشود. برای محدودیتهای بکاند TLS به --ca-native مراجعه کنید.
ارائه چندباره --proxy-ca-native تأثیر اضافهای ندارد. آن را دوباره با --no-proxy-ca-native غیرفعال کنید.
مثال:
curl --proxy-ca-native https://example.com
در نسخه 8.2.0 اضافه شد. همچنین ببینید --ca-native، --cacert، --capath، --dump-ca-embed و --insecure.
- --proxy-cacert <file>
- از پرونده
گواهی
مشخصشده
برای
اعتبارسنجی
پروکسی HTTPS
استفاده
میکند. این
پرونده
ممکن است
حاوی چندین
گواهی CA
باشد.
گواهی(ها)
باید در
قالب PEM
باشند.
این به شما امکان میدهد در مقایسه با سرور راه دوری که از طریق پروکسی به آن متصل شدهاید، از سطح اعتماد (trust) متفاوتی برای پروکسی استفاده کنید.
معادل --cacert است، اما در زمینه پروکسی HTTPS استفاده میشود.
اگر --proxy-cacert چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-cacert CA-file.txt -x https://proxy.example https://example.com
همچنین ببینید --proxy-capath، --cacert، --capath، --dump-ca-embed و --proxy.
- --proxy-capath <dir>
- مشابه --capath
است، اما در
زمینه
پروکسی HTTPS
استفاده
میشود.
از دایرکتوری گواهی مشخصشده برای اعتبارسنجی پروکسی استفاده میکند. میتوان چندین مسیر را با جدا کردن آنها با دونقطه (":") مشخص کرد (مانند "path1:path2:path3"). گواهیها باید در قالب PEM باشند، و اگر curl با OpenSSL ساخته شده باشد، دایرکتوری باید با استفاده از ابزار c_rehash ارائهشده همراه با OpenSSL پردازش شده باشد. در صورتی که پرونده --proxy-cacert حاوی گواهیهای CA متعددی باشد، استفاده از --proxy-capath میتواند به curl مبتنی بر OpenSSL امکان دهد اتصالات SSL را بسیار کارآمدتر از استفاده از --proxy-cacert برقرار کند.
اگر این گزینه تنظیم شود، مقدار پیشفرض capath نادیده گرفته میشود.
اگر --proxy-capath چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-capath /local/directory -x https://proxy.example https://example.com
همچنین ببینید --proxy-cacert، --proxy، --capath و --dump-ca-embed.
- --proxy-cert <cert[:passwd]>
- هنگام
برقراری
ارتباط با
یک پروکسی
HTTPS، از
پرونده
گواهی
کلاینت
مشخصشده
استفاده
میکند.
گواهی باید
در قالب PEM
باشد. اگر
گذرواژه
اختیاری
مشخص نشود،
در ترمینال
درخواست
میشود. از
--proxy-key برای
ارائه کلید
خصوصی
استفاده
کنید.
این گزینه معادل --cert است، اما در زمینه پروکسی HTTPS استفاده میشود.
اگر --proxy-cert چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-cert file -x https://proxy.example https://example.com
همچنین ببینید --proxy، --proxy-key و --proxy-cert-type.
- --proxy-cert-type <type>
- نوع گواهی
کارخواه
ارائهشده
را هنگام
استفاده از
پروکسی HTTPS
تعیین
میکند.
انواع PEM، DER،
ENG، PROV و P12
شناختهشده
هستند.
نوع پیشفرض به زیرساخت TLS بستگی دارد و معمولاً PEM است. برای Schannel مقدار آن P12 است. اگر --proxy-cert یک نشانی pkcs11: باشد، نوع پیشفرض ENG یا PROV خواهد بود (بسته به نسخهٔ OpenSSL).
معادل --cert-type است اما در زمینهٔ پروکسی HTTPS به کار میرود.
اگر --proxy-cert-type چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-cert-type PEM --proxy-cert file -x https://proxy.example https://example.com
همچنین --proxy-cert و --proxy-key را ببینید.
- --proxy-ciphers <list>
- (TLS) مشابه --ciphers
است اما در
زمینهٔ
پروکسی HTTPS
استفاده
میشود.
مشخص میکند که هنگام مذاکرهٔ TLS 1.2 (1.1, 1.0) از کدام مجموعههای رمز (cipher suites) در اتصال به پروکسی HTTPS شما استفاده شود. فهرست مجموعههای رمز باید رمزهای معتبری را مشخص کند. جزئیات مجموعه رمزها را در این نشانی بخوانید:
https://curl.se/docs/ssl-ciphers.html
اگر --proxy-ciphers چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 -x https://proxy.example https://example.com
همچنین --proxy-tls13-ciphers، --ciphers و --proxy را ببینید.
- --proxy-crlfile <file>
- نام
پروندهای
با قالب PEM
حاوی فهرست
ابطال
گواهی (CRL) را
مشخص
میکند که
تعیین
میکند
کدام
گواهیهای
همتا هنگام
برقراری
ارتباط با
یک پروکسی HTTPS
باطلشده
در نظر
گرفته شوند.
معادل --crlfile است اما تنها در زمینهٔ پروکسی HTTPS به کار میرود.
اگر --proxy-crlfile چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-crlfile rejects.txt -x https://proxy.example https://example.com
همچنین --crlfile و --proxy را ببینید.
- --proxy-digest
- هنگام
برقراری
ارتباط با
پروکسی
مشخصشده
از احراز
هویت HTTP Digest
استفاده
میکند. از
--digest برای
فعالسازی
HTTP Digest با یک
میزبان راه
دور
استفاده
کنید.
ارائهٔ چندبارهٔ --proxy-digest هیچ اثر اضافهای ندارد. آن را دوباره با --no-proxy-digest غیرفعال کنید.
مثال:
curl --proxy-digest --proxy-user user:passwd -x proxy https://example.com
همچنین --proxy، --proxy-anyauth و --proxy-basic را ببینید.
- --proxy-header <header/@file>
- (HTTP) سرآیند
اضافی برای
گنجاندن در
درخواست
هنگام
ارسال HTTP به
یک پروکسی.
میتوانید
هر تعداد
سرآیند
اضافی را
مشخص کنید.
این گزینه
معادل --header
است اما
تنها برای
ارتباط با
پروکسی
کاربرد
دارد؛
مانند
درخواستهای
CONNECT زمانی که
میخواهید
سرآیندی
جداگانه
نسبت به
آنچه به
میزبان راه
دور واقعی
ارسال
میشود، به
پروکسی
فرستاده
شود.
curl اطمینان حاصل میکند که هر سرآیندی که اضافه یا جایگزین میکنید با نشانگر پایان خط مناسب ارسال شود؛ بنابراین نباید آن را به عنوان بخشی از محتوای سرآیند اضافه کنید: خط جدید یا بازگشت به ابتدای خط اضافه نکنید، چرا که فقط کار را برای شما خراب میکنند.
سرآیندهای مشخصشده با این گزینه در درخواستهایی که curl میداند نباید به یک پروکسی ارسال شوند، گنجانده نمیشوند.
این گزینه میتواند آرگومانی به سبک @filename بپذیرد که در این صورت برای هر خط از پروندهٔ ورودی یک سرآیند اضافه میکند. استفاده از @- باعث میشود curl سرآیندها را از stdin بخواند.
از این گزینه میتوان چندین بار برای افزودن، جایگزینی یا حذف چندین سرآیند استفاده کرد.
--proxy-header میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl --proxy-header "X-First-Name: Joe" -x http://proxy https://example.com curl --proxy-header "User-Agent: surprise" -x http://proxy https://example.com curl --proxy-header "Host:" -x http://proxy https://example.com
همچنین --proxy و --header را ببینید.
- --proxy-http2
- (HTTP) مذاکره
برای HTTP/2 با یک
پروکسی HTTPS.
ممکن است
پروکسی
همچنان فقط
HTTP/1 را ارائه
دهد و در
این صورت curl
به استفاده
از همان
نسخه
پایبند
میماند.
این گزینه بر روی هیچ نوع پروکسی دیگری تأثیری ندارد.
این گزینه با "--proxy-http3" ناسازگار است.
مشخص کردن چندباره --proxy-http2 تأثیر اضافهای ندارد. آن را مجدداً با --no-proxy-http2 غیرفعال کنید.
مثال:
curl --proxy-http2 -x proxy https://example.com
برای کارکرد --proxy-http2، لازم است که libcurl زیرین با پشتیبانی از HTTP/2 ساخته شده باشد. این گزینه با --proxy-http3 ناسازگار است. اضافهشده در 8.1.0. همچنین ببینید: --proxy.
- --proxy-http3
- (HTTP) مذاکره
برای HTTP/3 با یک
پروکسی HTTPS.
اگر پروکسی
دادهشده
از HTTP/3
پشتیبانی
نکند،
انجام
انتقال با
شکست مواجه
میشود.
این گزینه بر روی هیچ نوع پروکسی دیگری تأثیری ندارد.
این گزینه با "--proxy-http2" ناسازگار است.
این ویژگی آزمایشی است و نیازمند ساختی است که پشتیبانی از پروکسی HTTP/3 در آن فعال شده باشد. برای ساختهای autotools از "--enable-proxy-http3" استفاده کنید. برای ساختهای CMake از "-DUSE_PROXY_HTTP3=ON" استفاده کنید.
مشخص کردن چندباره --proxy-http3 تأثیر اضافهای ندارد. آن را مجدداً با --no-proxy-http3 غیرفعال کنید.
مثال:
curl --proxy-http3 -x proxy https://example.com
برای کارکرد --proxy-http3، لازم است که libcurl زیرین با پشتیبانی از HTTP/3 ساخته شده باشد. این گزینه با --proxy-http2 ناسازگار است. اضافهشده در 8.21.0. همچنین ببینید: --proxy و --proxy-http2.
- --proxy-insecure
- مشابه --insecure
اما در
زمینه
پروکسی HTTPS به
کار میرود.
هر اتصال امنی که curl برقرار میکند، پیش از انجام انتقال برای امن بودن اعتبارسنجی میشود. این گزینه باعث میشود curl از مرحله اعتبارسنجی با یک پروکسی صرفنظر کرده و بدون بررسی ادامه دهد.
هنگامی که این گزینه برای یک پروکسی مبتنی بر HTTPS استفاده نشود، curl پیش از ادامه، گواهی TLS پروکسی را اعتبارسنجی میکند: اینکه گواهی شامل نام صحیحی باشد که با نام میزبان مطابقت دارد، و اینکه گواهی توسط یک گواهی CA موجود در مخزن گواهیها امضا شده باشد. برای جزئیات بیشتر به این منبع برخط مراجعه کنید: https://curl.se/docs/sslcerts.html
هشدار: استفاده از این گزینه، انتقال به پروکسی را ناامن میکند.
مشخص کردن چندباره --proxy-insecure تأثیر اضافهای ندارد. آن را مجدداً با --no-proxy-insecure غیرفعال کنید.
مثال:
curl --proxy-insecure -x https://proxy.example https://example.com
همچنین ببینید: --proxy و --insecure.
- --proxy-key <key>
- هنگام
استفاده از
گواهیهای
کارخواه با
پروکسی HTTPS،
نام پرونده
را برای
کلید خصوصی
خود مشخص
کنید. این
گزینه
معادل --key
است اما در
زمینه
پروکسی HTTPS به
کار میرود.
اگر --proxy-key چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --proxy-key here -x https://proxy.example https://example.com
همچنین ببینید: --proxy-key-type و --proxy.
- --proxy-key-type <type>
- نوع پرونده
کلید خصوصی
را که کلید
خصوصی
ارائهشده
با --proxy-key
استفاده
میکند،
مشخص کنید.
از DER، PEM و ENG
پشتیبانی
میشود. اگر
مشخص نشود،
PEM فرض
میشود.
معادل --key-type است اما در زمینه پروکسی HTTPS به کار میرود.
اگر --proxy-key-type چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --proxy-key-type DER --proxy-key here -x https://proxy.example https://example.com
همچنین ببینید: --proxy-key و --proxy.
- --proxy-negotiate
- هنگام
برقراری
ارتباط با
پروکسی
دادهشده،
از احراز
هویت HTTP Negotiate (SPNEGO)
استفاده
کنید. برای
فعال کردن HTTP
Negotiate (SPNEGO) با یک
میزبان
دوردست، از
--negotiate
استفاده
کنید.
ارائه چندباره --proxy-negotiate هیچ اثر اضافهای ندارد.
مثال:
curl --proxy-negotiate --proxy-user user:passwd -x proxy https://example.com
همچنین ببینید: --proxy-anyauth، --proxy-basic و --proxy-service-name.
- --proxy-ntlm
- هنگام
برقراری
ارتباط با
پروکسی
دادهشده،
از احراز
هویت HTTP NTLM
استفاده
کنید. برای
فعال کردن NTLM
با یک
میزبان
دوردست، از
--ntlm استفاده
کنید.
ارائه چندباره --proxy-ntlm هیچ اثر اضافهای ندارد. آن را دوباره با --no-proxy-ntlm غیرفعال کنید.
مثال:
curl --proxy-ntlm --proxy-user user:passwd -x http://proxy https://example.com
همچنین ببینید: --proxy-negotiate، --proxy-anyauth و --proxy-user.
- --proxy-pass <phrase>
- عبارت عبور
برای کلید
خصوصی
گواهی
کلاینت
پروکسی HTTPS.
معادل --pass است اما در زمینه پروکسی HTTPS استفاده میشود.
اگر --proxy-pass چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثال:
curl --proxy-pass secret --proxy-key here -x https://proxy.example https://example.com
همچنین ببینید: --proxy و --proxy-key.
- --proxy-pinnedpubkey <hashes>
- (TLS) از پرونده
کلید عمومی
(یا هشهای)
مشخصشده
برای تأیید
پروکسی
استفاده
کنید. این
میتواند
مسیری به یک
پرونده
باشد که
شامل یک
کلید عمومی
یکتا در
قالب PEM یا DER
است، یا هر
تعداد هش sha256
کدگذاریشده
با base64 که پیش
از آنها 'sha256//'
آمده و با ';'
از یکدیگر
جدا
شدهاند.
هنگام مذاکره یک اتصال TLS یا SSL، سرور گواهیای ارسال میکند که نشاندهنده هویت آن است. یک کلید عمومی از این گواهی استخراج میشود و اگر دقیقاً با کلید عمومی ارائهشده به این گزینه مطابقت نداشته باشد، curl پیش از ارسال یا دریافت هرگونه دادهای، اتصال را متوقف میکند.
قبل از curl 8.10.0 این گزینه به دلیل وجود یک باگ کار نمیکرد.
اگر --proxy-pinnedpubkey چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثالها:
curl --proxy-pinnedpubkey keyfile https://example.com curl --proxy-pinnedpubkey 'sha256//ce118b51897f4452dc' https://example.com
همچنین ببینید: --pinnedpubkey و --proxy.
- --proxy-service-name <name>
- تنظیم نام
سرویس برای
SPNEGO هنگام
انجام
احراز هویت
با پروکسی.
اگر --proxy-service-name چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثال:
curl --proxy-service-name "shrubbery" -x proxy https://example.com
همچنین ببینید: --service-name، --proxy و --proxy-negotiate.
- --proxy-ssl-allow-beast
- هنگام
برقراری
ارتباط با
یک پروکسی
HTTPS، نقص
امنیتی
پروتکل TLS1.0 را
که با عنوان
BEAST شناخته
میشود،
دور نزنید.
اگر از این
گزینه
استفاده
نشود، لایه
TLS ممکن است
از
روشهایی
برای دور
زدن
استفاده
کند که مشخص
شده باعث
ایجاد
مشکلات
سازگاری با
برخی از
پیادهسازیهای
قدیمیتر
سرور
میشوند.
این گزینه تنها نحوه اجرای TLS 1.0 توسط curl با یک پروکسی HTTPS را تغییر میدهد و هیچ اثری بر نسخههای بعدی TLS ندارد.
هشدار: این گزینه امنیت TLS را کاهش میدهد، و با استفاده از این پرچم شما دقیقاً همین را درخواست میکنید.
معادل --ssl-allow-beast است اما در زمینه پروکسی HTTPS استفاده میشود.
ارائه چندباره --proxy-ssl-allow-beast هیچ اثر اضافهای ندارد. آن را دوباره با --no-proxy-ssl-allow-beast غیرفعال کنید.
مثال:
curl --proxy-ssl-allow-beast -x https://proxy.example https://example.com
همچنین ببینید: --ssl-allow-beast و --proxy.
- --proxy-ssl-auto-client-cert
- مشابه --ssl-auto-client-cert
اما در
زمینهٔ
پروکسی HTTPS
استفاده
میشود.
این گزینه تنها توسط Schannel پشتیبانی میشود.
مشخص کردن چندبارهٔ --proxy-ssl-auto-client-cert اثر بیشتری ندارد. آن را دوباره با --no-proxy-ssl-auto-client-cert غیرفعال کنید.
مثال:
curl --proxy-ssl-auto-client-cert -x https://proxy.example https://example.com
در 7.77.0 اضافه شد. همچنین ببینید --ssl-auto-client-cert و --proxy.
- --proxy-tls13-ciphers <list>
- (TLS) مشابه --tls13-ciphers
اما در
زمینهٔ
پروکسی HTTPS
استفاده
میشود.
مجموعه رمزهای مورد استفاده در اتصال به پروکسی HTTPS را هنگام مذاکرهٔ TLS 1.3 مشخص کنید. فهرست مجموعه رمزها باید رمزهای معتبری را مشخص کند. دربارهٔ جزئیات مجموعه رمزهای TLS 1.3 در این نشانی وب بخوانید:
https://curl.se/docs/ssl-ciphers.html
این گزینه زمانی استفاده میشود که curl برای استفاده از OpenSSL 1.1.1 یا بالاتر، Schannel، wolfSSL، یا mbedTLS 3.6.0 یا بالاتر ساخته شده باشد.
پیش از curl 8.10.0 با mbedTLS یا wolfSSL، مجموعه رمزهای TLS 1.3 با استفاده از گزینهٔ --proxy-ciphers تنظیم میشدند.
اگر --proxy-tls13-ciphers چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-tls13-ciphers TLS_AES_128_GCM_SHA256 -x proxy https://example.com
همچنین ببینید --proxy-ciphers، --tls13-ciphers و --proxy.
- --proxy-tlsauthtype <type>
- گزینهٔ
منسوخشده.
این گزینه
از 8.22.0 به بعد
هیچ
عملکردی
ندارد.
نوع احراز هویت TLS را با پروکسی HTTPS تنظیم کنید. تنها گزینهٔ پشتیبانیشده "SRP"، برای TLS-SRP (RFC 5054) است. این گزینه تنها در صورتی کار میکند که libcurl زیربنایی با پشتیبانی از TLS-SRP ساخته شده باشد.
معادل --tlsauthtype اما در زمینهٔ پروکسی HTTPS استفاده میشود.
اگر --proxy-tlsauthtype چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-tlsauthtype SRP -x https://proxy.example https://example.com
همچنین ببینید --proxy، --proxy-tlsuser و --proxy-tlspassword.
- --proxy-tlspassword <string>
- گزینهٔ
منسوخشده.
این گزینه
از 8.22.0 به بعد
هیچ
عملکردی
ندارد.
گذرواژه مورد استفاده با روش احراز هویت TLS مشخصشده با --proxy-tlsauthtype را هنگام استفاده از پروکسی HTTPS تنظیم کنید. نیازمند این است که --proxy-tlsuser تنظیم شده باشد.
این گزینه با TLS 1.3 کار نمیکند.
معادل --tlspassword اما در زمینهٔ پروکسی HTTPS استفاده میشود.
اگر --proxy-tlspassword چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-tlspassword passwd -x https://proxy.example https://example.com
همچنین ببینید --proxy و --proxy-tlsuser.
- --proxy-tlsuser <name>
- گزینهٔ
منسوخشده.
این گزینه
از 8.22.0 به بعد
هیچ
عملکردی
ندارد.
نام کاربری مورد استفاده برای پروکسی HTTPS را با روش احراز هویت TLS مشخصشده با --proxy-tlsauthtype تنظیم کنید. نیازمند این است که --proxy-tlspassword نیز تنظیم شده باشد.
این گزینه با TLS 1.3 کار نمیکند.
اگر --proxy-tlsuser چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-tlsuser smith -x https://proxy.example https://example.com
همچنین ببینید --proxy و --proxy-tlspassword.
- --proxy-tlsv1
- هنگام
مذاکره با
یک پروکسی
HTTPS، حداقل از
TLS نسخه 1.x
استفاده
میکند. این
به معنای TLS
نسخه 1.0 یا
بالاتر است.
معادل با --tlsv1 اما برای بافتار یک پروکسی HTTPS.
ارائه چندباره --proxy-tlsv1 تأثیر اضافهای ندارد.
مثال:
curl --proxy-tlsv1 -x https://proxy.example https://example.com
همچنین ببینید --proxy.
- -U, --proxy-user <user:password>
- نام کاربری
و گذرواژه
را جهت
استفاده
برای احراز
هویت
پروکسی
مشخص میکند.
اگر از یک باینری curl با قابلیت SSPI در ویندوز استفاده میکنید و احراز هویت Negotiate یا NTLM را انجام میدهید، میتوانید با مشخص کردن یک دونقطه تک با این گزینه به curl بگویید که نام کاربری و گذرواژه را از متغیرهای محیطی شما انتخاب کند: "-U :".
در سیستمهایی که این قابلیت کار میکند، curl آرگومان دادهشده به گزینه را از فهرست فرایندها مخفی میکند. این برای محافظت از اعتبارنامهها در برابر مشاهده احتمالی توسط کاربران دیگر روی همان سیستم کافی نیست، زیرا آنها همچنان قبل از پاک شدن برای یک لحظه قابل مشاهده هستند. چنین دادههای حساسی باید در عوض از یک فایل یا موارد مشابه بازیابی شوند و هرگز به صورت متن آشکار در خط فرمان استفاده نشوند.
اگر --proxy-user چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --proxy-user smith:secret -x proxy https://example.com
همچنین ببینید --proxy-pass.
- --proxy1.0 <host[:port]>
- از پروکسی HTTP 1.0
مشخصشده
استفاده
میکند. اگر
شماره
درگاه مشخص
نشده باشد،
درگاه 1080 فرض
میشود.
تنها تفاوت میان این و گزینه پروکسی HTTP یعنی --proxy این است که تلاشها برای استفاده از CONNECT از طریق پروکسی، پروتکل HTTP 1.0 را به جای HTTP 1.1 پیشفرض مشخص میکند.
ارائه چندباره --proxy1.0 تأثیر اضافهای ندارد.
مثال:
curl --proxy1.0 http://proxy https://example.com
همچنین ببینید --proxy، --socks5 و --preproxy.
- -p, --proxytunnel
- هنگامی که
یک پروکسی HTTP
با --proxy
استفاده
میشود، این
گزینه موجب
میشود curl
ترافیک را
از طریق
پروکسی
تونل کند.
روش تونل با
درخواست CONNECT
در پروکسی HTTP
انجام
میشود و
مستلزم آن
است که
پروکسی
اجازه
اتصال
مستقیم به
شماره
درگاه
دوردستی را
که curl
میخواهد به
آن تونل
بزند، بدهد.
برای فرونشاندن سرآیندهای پاسخ CONNECT پروکسی هنگامی که curl برای نمایش سرآیندها در خروجی تنظیم شده است، از --suppress-connect-headers استفاده کنید.
ارائه چندباره --proxytunnel تأثیر اضافهای ندارد. آن را دوباره با --no-proxytunnel غیرفعال کنید.
مثال:
curl --proxytunnel -x http://proxy https://example.com
همچنین ببینید --proxy.
- --pubkey <key>
- (SFTP SCP) نام فایل
کلید عمومی.
به شما
اجازه
میدهد کلید
عمومی خود
را در این
فایل
جداگانه
ارائه دهید.
ابزار curl تلاش میکند تا کلید عمومی را به طور خودکار از فایل کلید خصوصی استخراج کند، بنابراین ارسال این گزینه عموماً لازم نیست. توجه داشته باشید که این استخراج کلید عمومی مستلزم آن است که libcurl با نسخهای از libssh2 نگارش 1.2.8 یا بالاتر پیوند خورده باشد که آن نیز خود با OpenSSL پیوند خورده است.
اگر --pubkey چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --pubkey file.pub sftp://example.com/
همچنین ببینید --pass.
- -Q, --quote <command>
- (FTP SFTP) ارسال یک
دستور
دلخواه به
سرور
دوردست FTP یا
SFTP. دستورهای
نقلقول (quote)
قبل از
انجام
انتقال
ارسال
میشوند
(دقیقاً
بلافاصله
پس از دستور
اولیه PWD در
یک انتقال FTP).
برای اینکه
دستورها پس
از یک
انتقال
موفق اجرا
شوند،
پیشوند یک
خط پیوند '-'
را به آنها
اضافه کنید.
(فقط FTP) برای اینکه دستورها پس از تغییر دایرکتوری کاری توسط curl، دقیقاً پیش از دستور(های) انتقال فایل ارسال شوند، پیشوند '+' را به دستور اضافه کنید.
میتوانید هر تعداد دستور را مشخص کنید.
به صورت پیشفرض curl در اولین شکست متوقف میشود. برای اینکه curl حتی در صورت شکست دستور به کار خود ادامه دهد، پیشوند یک ستاره (*) را به دستور اضافه کنید. در غیر این صورت، اگر سرور برای یکی از دستورها وضعیت شکست برگرداند، کل عملیات لغو میشود.
شما باید دستورهای FTP را با نحو معتبر آنگونه که RFC 959 تعریف میکند به سرورهای FTP، یا یکی از دستورهای فهرستشده در زیر را به سرورهای SFTP ارسال کنید.
پروتکل SFTP یک پروتکل باینری است. برخلاف FTP، ابزار curl دستورهای quote مربوط به SFTP را پیش از ارسال به سرور، خودش تفسیر میکند. نام پروندهها باید درون علامت نقلقول دوتایی قرار گیرند تا فاصلهها، بکاسلشها، نقلقولها یا نقلقولهای دوتایی درون آنها گنجانده شوند. درون علامت نقلقول دوتایی، توالیهای گریز زیر برای این منظور در دسترس هستند: \\، \" و \'.
در ادامه فهرست تمام دستورهای quote پشتیبانیشده در SFTP آمده است:
- atime date file
- دستور atime آخرین زمان دسترسی به پرونده مشخصشده توسط عملوند file را تنظیم میکند. عبارت date میتواند انواع مختلفی از رشتههای تاریخ باشد؛ برای جزئیات عبارت تاریخ، صفحه راهنمای curl_getdate(3) را ببینید. (اضافهشده در 7.73.0)
- chgrp group file
- دستور chgrp شناسه گروه (group ID) پرونده مشخصشده با عملوند file را به شناسه گروه تعیینشده با عملوند group تنظیم میکند. عملوند group یک شناسه گروه به صورت عدد صحیح دهدهی است.
- chmod mode file
- دستور chmod بیتهای حالت پرونده (file mode bits) را برای پرونده مشخصشده تغییر میدهد. عملوند mode یک عدد حالت به صورت عدد صحیح در مبنای هشت (اکتال) است.
- chown user file
- دستور chown مالک پرونده مشخصشده با عملوند file را به شناسه کاربری تعیینشده با عملوند user تنظیم میکند. عملوند user یک شناسه کاربری به صورت عدد صحیح دهدهی است.
- ln source_file target_file
- دستورهای ln و symlink یک پیوند نمادین در مکان target_file ایجاد میکنند که به مکان source_file اشاره دارد.
- mkdir directory_name
- دستور mkdir دایرکتوری مشخصشده با عملوند directory_name را ایجاد میکند.
- mtime date file
- دستور mtime آخرین زمان تغییر پرونده مشخصشده با عملوند file را تنظیم میکند. عبارت date میتواند انواع مختلفی از رشتههای تاریخ باشد؛ برای جزئیات عبارت تاریخ، صفحه راهنمای curl_getdate(3) را ببینید. (اضافهشده در 7.73.0)
- pwd
- دستور pwd مسیر مطلق دایرکتوری کاری جاری را برمیگرداند.
- rename source target
- دستور rename نام پرونده یا دایرکتوری مشخصشده با عملوند source را به مسیر مقصد مشخصشده با عملوند target تغییر میدهد.
- rm file
- دستور rm پرونده مشخصشده با عملوند file را حذف میکند.
- rmdir directory
- دستور rmdir ورودی دایرکتوری مشخصشده با عملوند directory را حذف میکند، به شرطی که خالی باشد.
- symlink source_file target_file
- دستور ln را ببینید.
-
گزینه --quote میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --quote "DELE file" ftp://example.com/foo
همچنین --request را ببینید.
- --random-file <file>
- گزینه
منسوخشده.
این گزینه
نادیده
گرفته
میشود
(اضافهشده
در 7.84.0). پیش از
آن تنها در
صورتی بر curl
تأثیر داشت
که برای
استفاده از
نسخههای
قدیمی OpenSSL
ساخته شده
باشد.
مسیر پرونده حاوی دادههای تصادفی را مشخص کنید. این دادهها ممکن است برای مقداردهی اولیه (seed) موتور تصادفی در اتصالات SSL استفاده شوند.
اگر --random-file چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --random-file rubbish https://example.com
همچنین --egd-file را ببینید.
- -r, --range <range>
- (HTTP FTP SFTP FILE) دریافت یک محدوده بایتی (یعنی بخشی از یک سند) از یک سرور HTTP/1.1، FTP یا SFTP یا یک FILE محلی. محدودهها را میتوان به روشهای مختلفی مشخص کرد.
- 0-499
- ۵۰۰ بایت اول را مشخص میکند
- 500-999
- ۵۰۰ بایت دوم را مشخص میکند
- -500
- ۵۰۰ بایت آخر را مشخص میکند
- 9500-
- بایتها را از آفست ۹۵۰۰ به بعد مشخص میکند
- 0-0,-1
- تنها بایت اول و آخر را مشخص میکند(*)(HTTP)
- 100-199,500-599
- دو محدوده جداگانه 100-بایتی را مشخص میکند(*) (HTTP)
- (*) = توجه
داشته
باشید که
اگر چندین
محدوده
مشخص کنید و
سرور از آن
پشتیبانی
کند، با یک
پاسخ
چندبخشی
پاسخ
میدهد که curl
آن را
همانطور
که هست (as-is)
بازمیگرداند.
این پاسخ
علاوه بر
بایتهای
درخواستشده،
حاوی
اطلاعات
فراداده (meta
information) نیز هست.
تجزیه یا
هرگونه
تبدیل این
پاسخ بر
عهده
فراخواننده
است.
تنها نویسههای رقمی (0-9) در فیلدهای 'start' و 'stop' در ساختار نحو محدوده 'start-stop' معتبر هستند. اگر نویسهای غیررقمی در محدوده داده شود، پاسخ سرور نامشخص خواهد بود و به پیکربندی سرور بستگی دارد.
بسیاری از سرورهای HTTP/1.1 این ویژگی را فعال نکردهاند، به طوری که هنگام تلاش برای دریافت یک محدوده، curl در عوض کل سند را دریافت میکند.
بارگیریهای محدوده در FTP و SFTP تنها از نحو ساده 'start-stop' پشتیبانی میکنند (بهصورت اختیاری با حذف یکی از اعداد). استفاده در FTP به دستور توسعهیافته FTP یعنی SIZE بستگی دارد.
هنگام استفاده از این گزینه برای بارگذاریهای HTTP با POST یا PUT، عملکرد آن تضمین نمیشود. پروتکل HTTP هیچ روش استاندارد و سازگاری برای ازسرگیری بارگذاری ندارد و curl برای این منظور از مجموعهای از هدرها استفاده میکند که زمانی اثبات شد برای برخی سرورها کار میکنند و برای کسانی که آن را مفید میدانند باقی گذاشته شدهاند.
این گزینه خط فرمان با --continue-at مانعةالجمع است: برای یک انتقال تنها میتوانید از یکی از آنها استفاده کنید.
اگر --range چندین بار ارائه شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --range 22-44 https://example.com
همچنین --continue-at و --append را ببینید.
- --rate <max request rate>
- حداکثر
بسامد
انتقالی را
مشخص
میکند که
به curl اجازه
استفاده از
آن را
میدهید -
بر حسب
تعداد شروع
انتقال در
واحد زمان
(که گاهی
نرخ
درخواست
نامیده
میشود).
بدون این
گزینه، curl
انتقال
بعدی را در
سریعترین
زمان ممکن
آغاز
میکند.
اگر چندین URL داده شده باشد و یک انتقال سریعتر از نرخ مجاز به پایان برسد، curl برای حفظ نرخ درخواستی، تا زمان شروع انتقال بعدی منتظر میماند. این گزینه هنگام استفاده از --parallel هیچ اثری ندارد.
نرخ درخواست به صورت "N/U" ارائه میشود که در آن N یک عدد صحیح و U یک واحد زمانی است. واحدهای پشتیبانیشده عبارتند از 's' (ثانیه)، 'm' (دقیقه)، 'h' (ساعت) و 'd' (روز، مانند یک واحد ۲۴ ساعته). اگر "/U" مشخص نشود، واحد زمانی پیشفرض تعداد انتقالها در ساعت است.
اگر به curl گفته شود که ۱۰ درخواست در دقیقه را مجاز بداند، تا زمانی که ۶ ثانیه از شروع انتقال قبلی سپری نشود، درخواست بعدی را آغاز نمیکند.
این قابلیت از دقت میلیثانیه استفاده میکند. اگر بسامد مجاز بیشتر از ۱۰۰۰ در ثانیه تنظیم شود، در عوض بدون محدودیت اجرا میشود.
هنگام تلاش مجدد برای انتقالها، که با --retry فعال میشود، منطق مجزای تأخیر تلاش مجدد استفاده میشود و نه این تنظیم.
از نسخه 8.10.0 به بعد، میتوانید تعداد واحدهای زمانی را در عبارت نرخ مشخص کنید. با "5/15s" کاری کنید curl بیش از ۵ انتقال در ۱۵ ثانیه انجام ندهد یا با "3/4h" آن را به ۳ انتقال در ۴ ساعت محدود کنید. هیچ فاصلهای مجاز نیست.
این گزینه سراسری است و نیازی به مشخص کردن آن برای هر بار استفاده از --next نیست.
اگر --rate چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --rate 2/s https://example.com ... curl --rate 3/h https://example.com ... curl --rate 14/m https://example.com ...
در 7.84.0 اضافه شد. همچنین --limit-rate و --retry-delay را ببینید.
- --raw
- (HTTP) هنگام
استفاده،
تمام
رمزگشاییهای
داخلی HTTP
مربوط به
محتوا یا
کدگذاریهای
انتقال را
غیرفعال
کرده و در
عوض باعث
میشود
آنها
دستنخورده
و خام منتقل
شوند.
مشخص کردن چندباره --raw اثر اضافهای ندارد. دوباره با --no-raw آن را غیرفعال کنید.
مثال:
curl --raw https://example.com
همچنین --tr-encoding را ببینید.
- -e, --referer <URL>
- (HTTP) نشانی (URL)
ارجاعدهنده
را در
درخواست HTTP
تنظیم
میکند.
البته این
مورد را
میتوان با
پرچم --header نیز
تنظیم کرد.
هنگام
استفاده
همراه با
--location
میتوانید
";auto" را به URL
گزینه --referer
ضمیمه کنید
تا وقتی curl یک
هدر Location: را
دنبال
میکند، به
طور خودکار
URL قبلی را
تنظیم کند.
رشته ";auto"
حتی اگر --referer
اولیهای
را تنظیم
نکرده
باشید،
میتواند
به تنهایی
استفاده
شود.
اگر --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
همچنین --user-agent و --header را ببینید.
- -J, --remote-header-name
- (HTTP) به گزینه
--remote-name
میگوید به
جای
استخراج
نام پرونده
از URL، از نام
پرونده
مشخصشده
توسط سرور
در Content-Disposition
استفاده
کند. اگر
نام پرونده
ارائهشده
توسط سرور
شامل یک
مسیر باشد،
پیش از
استفاده از
نام
پرونده، آن
مسیر حذف
میشود.
پرونده در دایرکتوری جاری، یا در دایرکتوری مشخصشده با --output-dir ذخیره میشود.
اگر سرور نام پروندهای را مشخص کند و پروندهای با همان نام از قبل در دایرکتوری مقصد وجود داشته باشد، بازنویسی نمیشود و خطایی رخ میدهد - مگر اینکه با استفاده از گزینه --clobber به آن اجازه دهید. اگر سرور نام پروندهای را مشخص نکند، این گزینه هیچ اثری نخواهد داشت.
(هنوز) هیچ تلاشی برای رمزگشایی توالیهای %- در نام پرونده ارائهشده انجام نمیشود، بنابراین این گزینه ممکن است نام پروندههای نسبتاً غیرمنتظرهای به شما ارائه دهد.
این قابلیت از نام موجود در فیلد "filename" استفاده میکند و هنوز از فیلد "filename*" (نامهای پرونده با مجموعهنویسههای صریح) پشتیبانی نمیکند.
از نسخه 8.19.0 به بعد، اگر هیچ هدر "Content-Disposition:" نام پروندهای ارائه ندهد، curl عقبگرد کرده و از نام پرونده استخراجشده از آخرین هدر بازهدایت استفاده میکند.
هشدار: در استفاده از این گزینه، بهویژه در Windows، محتاط باشید. یک سرور سرکش میتواند نام یک پرونده DLL یا پرونده دیگری را برای شما ارسال کند که ممکن است به طور خودکار توسط Windows یا یک نرمافزار شخص ثالث بارگذاری شود.
مشخص کردن چندباره --remote-header-name اثر اضافهای ندارد. دوباره با --no-remote-header-name آن را غیرفعال کنید.
مثال:
curl -OJ https://example.com/file
همچنین --remote-name را ببینید.
- -O, --remote-name
- خروجی را در
یک پروندهٔ
محلی
همنام با
پروندهٔ
دوری که
دریافت
میشود
مینویسد.
(تنها بخش
نام پرونده
از پروندهٔ
دور
استفاده
میشود و
مسیر آن حذف
میگردد.)
پرونده در دایرکتوری کاری فعلی ذخیره میشود. اگر میخواهید پرونده در دایرکتوری دیگری ذخیره شود، مطمئن شوید که پیش از فراخوانی curl با این گزینه دایرکتوری کاری فعلی را تغییر دادهاید یا از --output-dir استفاده کنید.
نام پروندهٔ دور برای ذخیرهسازی، تنها از URL دادهشده استخراج میشود و نه هیچ چیز دیگر، و اگر از قبل وجود داشته باشد رونویسی میشود. اگر میخواهید سرور بتواند نام پرونده را تعیین کند، به --remote-header-name مراجعه کنید که میتواند علاوه بر این گزینه استفاده شود. اگر سرور نام پرونده را تعیین کند و آن نام از قبل وجود داشته باشد، رونویسی نمیشود.
هیچ رمزگشایی URL روی نام پرونده انجام نمیشود. اگر نام دارای %20 یا سایر بخشهای کدگذاریشدهٔ URL باشد، همانطور که هست (as-is) به عنوان نام پرونده قرار میگیرد.
میتوانید از این گزینه به تعداد URLهایی که دارید استفاده کنید.
پیش از curl 8.10.0، اگر URL با یک اسلش پایان مییافت curl یک خطا برمیگرداند، که به این معنی بود هیچ بخش نام پروندهای در URL وجود ندارد. از نسخهٔ 8.10.0 به بعد، curl در این شرایط نام پرونده را روی آخرین بخش دایرکتوری از URL تنظیم میکند، یا اگر آن هم وجود نداشته باشد، روی "curl_response" (بدون پسوند) قرار میدهد.
گزینهٔ --remote-name با یک URL منفرد مرتبط است. هنگامی که از چندین URL در یک خط فرمان استفاده میکنید، آن را برای هر URL یک بار به کار ببرید.
مثالها:
curl -O https://example.com/filename curl -O https://example.com/filename -O https://example.com/file2
همچنین ببینید: --remote-name-all، --output-dir و --remote-header-name.
- --remote-name-all
- عملکرد
پیشفرض را
برای همهٔ
URLهای
دادهشده
تغییر
میدهد تا
طوری با
آنها
برخورد شود
که گویی
برای
هرکدام از
--remote-name
استفاده
شده است.
اگر
میخواهید
این رفتار
را پس از
استفاده از
--remote-name-all برای یک
URL خاص
غیرفعال
کنید، باید
از "-o -" یا --no-remote-name
استفاده
کنید.
ارائهٔ چندینبارهٔ --remote-name-all هیچ اثر اضافهای ندارد. آن را دوباره با --no-remote-name-all غیرفعال کنید.
مثال:
curl --remote-name-all ftp://example.com/file1 ftp://example.com/file2
همچنین ببینید: --remote-name.
- -R, --remote-time
- باعث
میشود curl
تلاش کند
برچسب
زمانی (timestamp)
پروندهٔ
دور در حال
بارگیری را
بیابد، و در
صورت در
دسترس
بودن، کاری
کند که
پروندهٔ
محلی همان
برچسب
زمانی را
دریافت کند.
ارائهٔ چندینبارهٔ --remote-time هیچ اثر اضافهای ندارد. آن را دوباره با --no-remote-time غیرفعال کنید.
مثال:
curl --remote-time -o foo https://example.com
همچنین ببینید: --remote-name و --time-cond.
- --remove-on-error
- در صورت
بروز خطا،
پروندهٔ
خروجی را
حذف
میکند؛
هنگامی که
به curl گفته
شده باشد
خروجی را در
یک پروندهٔ
محلی ذخیره
کند و با
خطا مواجه
شود. این
کار مانع از
آن میشود
که curl در صورت
بروز خطا در
حین
انتقال، یک
پروندهٔ
ناقص بر جای
بگذارد.
اگر خروجی یک پروندهٔ معمولی (regular file) نباشد، این گزینه هیچ اثری ندارد.
گزینهٔ --continue-at نمیتواند همراه با --remove-on-error استفاده شود.
ارائهٔ چندینبارهٔ --remove-on-error هیچ اثر اضافهای ندارد. آن را دوباره با --no-remove-on-error غیرفعال کنید.
مثال:
curl --remove-on-error -o output https://example.com
افزودهشده در 7.83.0. همچنین ببینید: --fail.
- -X, --request <method>
- متد مورد
استفاده
هنگام آغاز
انتقال را
تغییر
میدهد.
curl رشتهٔ ارائهشده را عیناً و بدون هیچگونه پالایش یا سایر تدابیر حفاظتی در درخواست ارسال میکند. این موضوع شامل نویسههای فاصله و نویسههای کنترلی نیز میشود.
- HTTP
- یک متد
درخواست
سفارشی را
برای
استفاده
هنگام
برقراری
ارتباط با
سرور HTTP مشخص
میکند. متد
درخواستِ
مشخصشده
به جای متدی
که در حالت
عادی
استفاده
میشد (که
پیشفرض آن
GET است) به
کار میرود.
برای
جزئیات و
توضیحات،
مشخصات HTTP 1.1 را
مطالعه
کنید.
درخواستهای
رایج و
اضافی دیگر
HTTP شامل PUT و DELETE
هستند، در
حالی که
فناوریهای
مرتبط
مانند WebDAV
متدهای PROPFIND،
COPY، MOVE و
موارد
بیشتری را
ارائه
میدهند.
به طور معمول به این گزینه نیازی ندارید. انواع درخواستهای GET، HEAD، POST و PUT معمولاً با استفاده از گزینههای اختصاصی خط فرمان فراخوانی میشوند.
این گزینه تنها واژهٔ واقعیِ بهکاررفته در درخواست HTTP را تغییر میدهد، و شیوهٔ رفتار curl را دگرگون نمیکند. برای نمونه اگر میخواهید یک درخواست مناسب HEAD ایجاد کنید، استفاده از -X HEAD کافی نیست. باید از گزینهٔ --head استفاده کنید.
اگر از --location استفاده شود، رشتهٔ متدی که با --request تنظیم کردهاید برای همهٔ درخواستها استفاده میشود، که میتواند زمانی که curl متد درخواست را مطابق با کدهای پاسخ 30x پروتکل HTTP - و موارد مشابه - تغییر نمیدهد، باعث عوارض جانبی ناخواسته (side-effects) شود. در عوض، استفاده از --follow را در ترکیب با --request در نظر بگیرید.
- FTP
- یک دستور سفارشی FTP را برای استفاده بهجای LIST هنگام فهرستکردن فایلها با FTP مشخص میکند.
- POP3
- یک دستور سفارشی POP3 را برای استفاده بهجای LIST یا RETR مشخص میکند.
- IMAP
- یک دستور سفارشی IMAP را برای استفاده بهجای LIST مشخص میکند.
- SMTP
- یک دستور سفارشی SMTP را برای استفاده بهجای HELP یا VRFY مشخص میکند.
-
اگر --request چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --request "DELETE" https://example.com curl -X NLST ftp://example.com/
همچنین --request-target و --follow را ببینید.
- --request-target <path>
- (HTTP) استفاده
از یک مقصد
(مسیر)
جایگزین
بهجای
استفاده از
مسیر
ارائهشده
در URL. این
گزینه
بهویژه
زمانی مفید
است که
میخواهید
درخواستهای
HTTP بدون اسلش
ابتدایی یا
با
دادههای
دیگری که از
الگوی
معمول URL
پیروی
نمیکنند
(مانند "OPTIONS *")،
ارسال شوند.
curl رشتهای را که به آن میدهید عیناً و بدون هیچگونه فیلتر یا محافظت دیگری در درخواست ارسال میکند. این شامل نویسههای فاصله و نویسههای کنترلی نیز میشود.
اگر --request-target چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --request-target "*" -X OPTIONS https://example.com
همچنین --request را ببینید.
- --resolve <[+]host:port:addr[,addr]...>
- یک نشانی
سفارشی
برای یک جفت
میزبان و
پورت مشخص
ارائه
میدهد. با
استفاده از
این گزینه،
میتوانید
کاری کنید
که
درخواست(های)
curl از یک
نشانی
تعیینشده
استفاده
کنند و از
بهکارگیری
نشانیای
که در حالت
عادی تفکیک
میشد
جلوگیری
نمایید. این
گزینه را
نوعی
جایگزین /etc/hosts
در خط فرمان
در نظر
بگیرید.
شماره پورت
باید همان
شمارهای
باشد که
برای
پروتکل خاص
مورد
استفادهٔ
میزبان به
کار میرود.
این یعنی
اگر
بخواهید
برای یک
میزبان اما
با
پورتهای
مختلف
نشانی
تعیین
کنید، به
چندین
ورودی نیاز
خواهید
داشت.
با مشخصکردن "*" بهعنوان میزبان، میتوانید به curl بگویید که هر میزبانی با آن پورت مشخص را به نشانی تعیینشده تفکیک کند. نویسهٔ عام (Wildcard) در آخر تفکیک میشود، بنابراین هر --resolve با میزبان و پورت خاص در ابتدا اعمال خواهد شد.
نشانی تعیینشده توسط این گزینه حتی در صورتی که --ipv4 یا --ipv6 برای وادارکردن curl به استفاده از نسخهٔ دیگری از IP تنظیم شده باشد، استفاده میشود.
با افزودن پیشوند '+' به ابتدای میزبان، میتوانید کاری کنید که این ورودی پس از مهلت زمانی پیشفرض curl (۱ دقیقه) منقضی شود. توجه داشته باشید که این کار تنها برای انتقالهای موازی طولانیمدت با تعداد زیادی فایل منطقی است. در چنین مواردی، در صورت استفاده از این گزینه، پس از انقضای مهلت زمانی، curl تلاش میکند میزبان را به همان روش معمول تفکیک کند.
نشانیهای IPv6 را درون [قلابها] وارد کنید.
برای تغییر مسیر اتصالها از یک نام میزبان خاص یا هر نام میزبانی، صرفنظر از شماره پورت، گزینهٔ --connect-to را در نظر داشته باشید.
پشتیبانی از تفکیک با نویسهٔ عام در نسخهٔ 7.64.0 اضافه شد.
پشتیبانی از پیشوند '+' در نسخهٔ 7.75.0 اضافه شد.
پشتیبانی از تعیین بخش میزبان بهصورت نشانی IPv6 در نسخهٔ 8.13.0 اضافه شد.
--resolve میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl --resolve example.com:443:127.0.0.1 https://example.com curl --resolve example.com:443:[2001:db8::252f:efd6] https://example.com
همچنین --connect-to و --alt-svc را ببینید.
- --retry <num>
- اگر هنگام
تلاش curl برای
انجام یک
انتقال،
خطای گذرا
بازگردانده
شود، قبل از
انصراف به
این تعداد
بار تلاش
مجدد
میکند.
تنظیم این
عدد روی 0
باعث
میشود curl
هیچ تلاشی
مجددی
انجام ندهد
(که حالت
پیشفرض
است). خطای
گذرا به یکی
از این
موارد گفته
میشود:
اتمام مهلت
زمانی (timeout)،
کد پاسخ FTP 4xx یا
کد پاسخ HTTP 408،
429، 500، 502، 503، 504، 522
یا 524.
هنگامی که curl قصد تلاش مجدد برای یک انتقال را دارد، ابتدا یک ثانیه صبر میکند و سپس برای تمامی تلاشهای بعدی، زمان انتظار را دو برابر میکند تا به ۱۰ دقیقه برسد؛ پس از آن، این مقدار بهعنوان زمان تأخیر ثابت بین باقیماندهٔ تلاشها حفظ میشود. با استفاده از --retry-delay میتوانید این الگوریتم عقبنشینی نمایی را غیرفعال کنید. همچنین --retry-max-time را برای محدودکردن کل زمان مجاز برای تلاشهای مجدد ببینید.
برنامه curl در صورت وجود سرایند پاسخ Retry-After: از آن پیروی میکند تا بداند چه زمانی تلاش بعدی را انجام دهد (در نسخهٔ 7.66.0 اضافه شد).
اگر --retry چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --retry 7 https://example.com
همچنین --retry-max-time، --retry-connrefused و --retry-delay را ببینید.
- --retry-all-errors
- تلاش مجدد
در صورت
بروز
هرگونه خطا.
این گزینه
همراه با --retry
استفاده
میشود.
این گزینه حکم «پتک» در تلاشهای مجدد را دارد. از این گزینه بهصورت پیشفرض (برای نمونه در curlrc خود) استفاده نکنید، چرا که ممکن است پیامدهای ناخواستهای مانند ارسال یا دریافت دادههای تکراری داشته باشد. از آن همراه با ورودی یا خروجی تغییرمسیریافته استفاده نکنید. شاید بهتر باشد مشکلات خاص خود را در یک اسکریپت شل مدیریت کنید. لطفاً مثال زیر را بخوانید.
هشدار: برای سازگاری با سرور، curl تلاش میکند انتقالهای ناموفق و ناپایدار را تا جای ممکن شبیه به نحوه آغاز اولیهشان تکرار کند، اما این کار با ورودی یا خروجی تغییرمسیریافته شدنی نیست. برای نمونه، پیش از تلاش مجدد، دادههای خروجی یک انتقال ناقص و ناموفق را که در پرونده خروجی نوشته شده بود حذف میکند. با این حال، این موضوع برای دادههای هدایتشده به یک لوله (| pipe) یا پرونده (> file) که بازنشانی نمیشوند، صدق نمیکند. اکیداً پیشنهاد میکنیم هنگام استفاده از این گزینه، خروجی را از طریق تغییر مسیر پردازش یا ذخیره نکنید، چرا که ممکن است دادههای تکراری دریافت کنید.
بهطور پیشفرض اگر انتقال موفقیتآمیز باشد، curl برای انتقالهایی با کد پاسخ HTTP که نشاندهنده خطای HTTP است، خطایی برنمیگرداند. برای نمونه، اگر سرور پاسخ 404 Not Found بدهد و پاسخ بهطور کامل دریافت شود، این یک خطا به شمار نمیآید. هنگامی که از --retry استفاده میشود، curl روی برخی کدهای پاسخ HTTP که بیانگر خطاهای گذرا هستند دوباره تلاش میکند، اما این شامل اکثر کدهای پاسخ 4xx مانند 404 نمیشود. اگر میخواهید روی همه کدهای پاسخی که نشاندهنده خطاهای HTTP هستند (4xx و 5xx) تلاش مجدد انجام شود، آن را با --fail ترکیب کنید.
ارائه چندباره --retry-all-errors تأثیر اضافهای ندارد. با --no-retry-all-errors دوباره آن را غیرفعال کنید.
مثال:
curl --retry 5 --retry-all-errors https://example.com
در 7.71.0 افزوده شد. همچنین ببینید: --retry.
- --retry-connrefused
- علاوه بر
سایر
شرایط، ECONNREFUSED
را نیز به
عنوان یک
خطای گذرا
برای --retry در
نظر
میگیرد.
این گزینه
همراه با --retry
استفاده
میشود. در
حالت عادی،
اتصال
ردشده یک
خطای گذرا
در نظر
گرفته
نمیشود و
بنابراین
در غیر این
صورت تلاشی
مجدد را
آغاز
نخواهد کرد.
ارائه چندباره --retry-connrefused تأثیر اضافهای ندارد. با --no-retry-connrefused دوباره آن را غیرفعال کنید.
مثال:
curl --retry-connrefused --retry 7 https://example.com
همچنین ببینید: --retry و --retry-all-errors.
- --retry-delay <seconds>
- باعث
میشود curl
هنگام شکست
یک انتقال
به دلیل
خطای گذرا،
پیش از هر
تلاش مجدد
این مدت
زمان مکث
کند (این
گزینه
الگوریتم
پیشفرض
زمان
پسنشینی
بین
تلاشهای
مجدد را
تغییر
میدهد).
این گزینه
تنها زمانی
کاربرد
دارد که --retry
نیز
استفاده
شده باشد.
تنظیم این
تاخیر روی
صفر باعث
میشود curl از
زمان
پسنشینی
پیشفرض
استفاده
کند.
بهطور پیشفرض، curl از مهلت زمانی با افزایش نمایی بین تلاشهای مجدد استفاده میکند.
از نسخه 8.16.0 curl به بعد، این گزینه زمان را بهصورت یک عدد اعشاری برای کسرهایی از ثانیه میپذیرد. مقدار اعشاری باید با استفاده از نقطه (.) به عنوان جداکننده اعشار ارائه شود - نه نسخه محلی، حتی اگر از جداکننده دیگری استفاده کند.
اگر --retry-delay چندین بار ارائه شود، آخرین مقدار تنظیمشده به کار میرود.
مثال:
curl --retry-delay 5 --retry 7 https://example.com
همچنین ببینید: --retry و --retry-max-time.
- --retry-max-time <seconds>
- تایمر تلاش
مجدد پیش از
اولین
اقدام برای
انتقال
بازنشانی
میشود.
تلاشهای
مجدد تا
زمانی که
تایمر به
این حد
مشخصشده
نرسیده
باشد، طبق
روال معمول
(ببینید: --retry)
انجام
میشوند.
توجه داشته
باشید که
اگر تایمر
به این حد
نرسیده
باشد،
درخواست
فرستاده
میشود و
حین اجرا
ممکن است
بیشتر از
این بازه
زمانی مشخص
طول بکشد.
برای محدود
کردن
حداکثر
زمان یک
درخواست
تکی، از --max-time
استفاده
کنید. این
گزینه را
روی صفر
تنظیم کنید
تا
تلاشهای
مجدد منقضی
نشوند.
تایمر تلاش مجدد بلافاصله پیش از اولین اقدام برای انتقال آغاز میشود و زمان سپریشده در مکث بین تلاشهای مجدد (مانند تاخیرهای تعریفشده با --retry-delay) را نیز در بر میگیرد. پیش از شروع هر تلاش مجدد تازه، curl بررسی میکند که آیا زمان سپریشده به حد تعیینشده رسیده است یا خیر. اگر رسیده باشد، تلاش مجدد دیگری انجام نمیشود.
به انتقالی که از قبل آغاز شده اجازه داده میشود تا پایان ادامه یابد، حتی اگر این امر باعث شود کل زمان واقعی (wall clock time) از حد مجاز فراتر رود. همچنین از --max-time برای تعیین سقف مدتزمان هر اقدام انتقال تکی استفاده کنید.
از نسخه 8.16.0 curl به بعد، این گزینه زمان را بهصورت یک عدد اعشاری برای کسرهایی از ثانیه میپذیرد. مقدار اعشاری باید با استفاده از نقطه (.) به عنوان جداکننده اعشار ارائه شود - نه نسخه محلی، حتی اگر از جداکننده دیگری استفاده کند.
اگر --retry-max-time چندین بار ارائه شود، آخرین مقدار تنظیمشده به کار میرود.
مثال:
curl --retry-max-time 30 --retry 10 https://example.com
همچنین ببینید: --retry و --retry-delay.
- --sasl-authzid <identity>
- (LDAP IMAP POP3 SMTP) در طول
احرازهویت
SASL PLAIN، علاوه
بر شناسه
احرازهویت
(authcid) که توسط
--user مشخص شده
است، از این
شناسه
مجازسازی
(authzid) استفاده
کنید.
اگر این گزینه مشخص نشود، سرور authzid را از روی authcid استخراج میکند، اما در صورت مشخص شدن، و بسته به پیادهسازی سرور، ممکن است برای دسترسی به صندوق دریافت کاربری دیگر که به این کاربر دسترسی آن داده شده است، یا مثلاً یک صندوق پستی مشترک استفاده شود.
اگر --sasl-authzid چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --sasl-authzid zid imap://example.com/
در نسخه 7.66.0 افزوده شد. همچنین ببینید --login-options.
- --sasl-ir
- (LDAP IMAP POP3 SMTP) پاسخ
اولیه را در
احرازهویت
SASL فعال
میکند. چنین
«پاسخ
اولیهای»
پیامی است
که پس از
انتخاب
سازوکار
احرازهویت
توسط
کلاینت، از
سوی کلاینت
به سرور
ارسال
میشود.
ارائه چندین باره --sasl-ir تأثیر اضافهای ندارد. با --no-sasl-ir دوباره آن را غیرفعال کنید.
مثال:
curl --sasl-ir imap://example.com/
همچنین ببینید --sasl-authzid.
- --service-name <name>
- نام سرویس
را برای SPNEGO
تنظیم
میکند.
اگر --service-name چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --service-name sockd/server https://example.com
همچنین ببینید --negotiate و --proxy-service-name.
- -S, --show-error
- هنگامی که
همراه با --silent
استفاده
شود، باعث
میشود در
صورت بروز
خطا یا
شکست، curl یک
پیام خطا
نمایش دهد.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
ارائه چندین باره --show-error تأثیر اضافهای ندارد. با --no-show-error دوباره آن را غیرفعال کنید.
مثال:
curl --show-error --silent https://example.com
همچنین ببینید --no-progress-meter.
- -i, --show-headers
- (HTTP FTP)
سرایندهای
پاسخ را در
خروجی
نمایش
میدهد.
سرایندهای
پاسخ HTTP
میتوانند
شامل
مواردی
مانند نام
سرور،
کوکیها،
تاریخ سند،
نسخه HTTP و
غیره باشند.
در
پروتکلهای
غیر HTTP،
منظور از
«سرایندها»
سایر
ارتباطات
سرور است.
این گزینه باعث میشود سرایندهای پاسخ در همان جریان/خروجی دادهها ذخیره شوند. گزینه --dump-header برای ذخیره سرایندها در یک جریان جداگانه وجود دارد.
هنگامی که سرایندهای HTTP به یک tty خروجی داده میشوند، curl ممکن است از کدهای فرار استفاده کند تا نام فیلدهای سرایند به صورت پررنگ (bold) نمایش داده شوند و نشانیهای وب در سرایندهای "Location:" به طور ویژهای متمایز گردند. استفاده از کدهای فرار ترمینال را با --no-styled-output غیرفعال کنید. (این به معنای استفاده از گزینه --styled-output همراه با پیشوند "--no-" برای غیرفعال کردن آن است.)
برای مشاهده سرایندهای درخواست، گزینه --verbose را در نظر بگیرید.
پیش از نسخه 7.75.0، اگر --fail در ترکیب با این گزینه استفاده میشد و خطایی توسط سرور گزارش میگردید، curl سرایندها را چاپ نمیکرد.
این گزینه پیش از نسخه 8.10.0 با نام --include خوانده میشد. نام قبلی همچنان کاربردی و فعال است.
ارائه چندین باره --show-headers تأثیر اضافهای ندارد. با --no-show-headers دوباره آن را غیرفعال کنید.
مثال:
curl -i https://example.com
همچنین ببینید --verbose و --dump-header.
- --sigalgs <list>
- (TLS)
الگوریتمهای
امضای
مشخصی را
برای
استفاده
هنگام
برقراری
نشست SSL
مطابق با RFC 5246،
بخش 7.4.1.4.1
تنظیم
میکند.
یک الگوریتم میتواند از یک جفت الگوریتم امضا و الگوریتم هش که با یک "+" از هم جدا شدهاند (مانند "ECDSA+SHA224")، یا نام طرح امضای TLS 1.3 آن (مانند "ed25519") استفاده کند.
میتوان چندین الگوریتم را با جدا کردن آنها توسط ":" ارائه داد (مانند "DSA+SHA256:rsa_pss_pss_sha256"). این پارامتر به صورت "-sigalgs" در ابزارهای "s_client" و "s_server" متعلق به OpenSSL در دسترس است.
گزینه "--sigalgs" به نسخهای از curl که بر پایه OpenSSL است اجازه میدهد اتصالهای SSL را دقیقاً با همان الگوریتمهای امضای درخواستی کلاینت برقرار کند و از مذاکرات غیرشفاف بین کلاینت و سرور جلوگیری مینماید.
اگر این گزینه تنظیم شود، فهرست پیشفرض الگوریتمهای امضا که در OpenSSL تعبیه شده است، نادیده گرفته میشود.
اگر --sigalgs چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --sigalgs ecdsa_secp256r1_sha256 https://example.com
در نسخه 8.14.0 افزوده شد. همچنین ببینید --ciphers.
- -s, --silent
- حالت
بیصدا یا
ساکت.
نشانگر
پیشرفت،
پیامهای
یادداشت،
پیامهای
هشدار یا
پیامهای
خطا را
نمایش
نمیدهد. curl
را بیصدا
میکند.
همچنان
دادههایی
را که
درخواست
کردهاید
خروجی
میدهد، که
اگر آن را
تغییر مسیر
ندهید حتی
ممکن است در
terminal/stdout نمایش
داده شود.
برای غیرفعال کردن نشانگر پیشرفت و در عین حال نمایش پیامهای خطا، علاوه بر این گزینه از --show-error استفاده کنید.
ارائه چندباره --silent اثر اضافهای ندارد. با --no-silent دوباره آن را غیرفعال کنید.
مثال:
curl -s https://example.com
همچنین --verbose، --stderr و --no-progress-meter را ببینید.
- --skip-existing
- اگر هنگام
درخواست
دانلود، یک
فایل محلی
موجود
باشد، از
عملیات
صرفنظر
میشود.
توجه داشته
باشید که curl
نمیتواند
بداند که
آیا فایل
محلی قبلاً
بهدرستی
دانلود شده
است، یا
اینکه ناقص
است و غیره؛
تنها وجود
داشتن یا
نداشتن نام
فایل در
سامانه
فایل را
تشخیص
میدهد و در
صورت وجود،
از انتقال
صرفنظر
میکند.
ارائه چندباره --skip-existing اثر اضافهای ندارد. با --no-skip-existing دوباره آن را غیرفعال کنید.
مثال:
curl --skip-existing --output local/dir/file https://example.com
در 8.10.0 اضافه شد. همچنین --output، --remote-name و --no-clobber را ببینید.
- --socks4 <host[:port]>
- از پراکسی SOCKS4
مشخصشده
استفاده
کنید. اگر
شماره پورت
مشخص نشده
باشد، پورت
1080 فرض
میشود.
استفاده از
این نوع
سوکت باعث
میشود curl
نام میزبان
را تحلیل
کرده و
نشانی را به
پراکسی
ارسال کند.
برای تعیین پراکسی روی یک Unix domain socket، از localhost برای host استفاده کرده و مسیر مطلق سوکت دامنه را ضمیمه کنید. برای مثال: "socks4://localhost/path/to/socket.sock" (طرحواره یا scheme میتواند حذف شود).
این گزینه هرگونه استفاده قبلی از --proxy را لغو میکند، چرا که این گزینهها مانعةالجمع هستند.
این گزینه زائد است چرا که میتوانید با استفاده از یک پیشوند پروتکل "socks4://"، یک پراکسی socks4 را با --proxy مشخص کنید.
میتوان از --preproxy برای مشخص کردن یک پراکسی SOCKS همزمان با استفاده از پراکسی به همراه یک پراکسی HTTP/HTTPS استفاده کرد. در چنین حالتی، curl ابتدا به پراکسی SOCKS وصل میشود و سپس (از طریق SOCKS) به پراکسی HTTP یا HTTPS متصل میگردد.
اگر --socks4 چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --socks4 hostname:4096 https://example.com
این گزینه با --proxy، --socks4a، --socks5 و --socks5-hostname مانعةالجمع است. همچنین --socks4a، --socks5 و --socks5-hostname را ببینید.
- --socks4a <host[:port]>
- از پراکسی SOCKS4a
مشخصشده
استفاده
کنید. اگر
شماره پورت
مشخص نشده
باشد، پورت
1080 فرض
میشود. این
گزینه از
پراکسی
میخواهد
که نام
میزبان را
تحلیل کند.
برای تعیین پراکسی روی یک Unix domain socket، از localhost برای host استفاده کرده و مسیر مطلق سوکت دامنه را ضمیمه کنید. برای مثال: "socks4a://localhost/path/to/socket.sock" (طرحواره یا scheme میتواند حذف شود).
این گزینه هرگونه استفاده قبلی از --proxy را لغو میکند، چرا که این گزینهها مانعةالجمع هستند.
این گزینه زائد است چرا که میتوانید با استفاده از یک پیشوند پروتکل "socks4a://"، یک پراکسی socks4a را با --proxy مشخص کنید.
میتوان از --preproxy برای مشخص کردن یک پراکسی SOCKS همزمان با استفاده از --proxy به همراه یک پراکسی HTTP/HTTPS استفاده کرد. در چنین حالتی، curl ابتدا به پراکسی SOCKS وصل میشود و سپس (از طریق SOCKS) به پراکسی HTTP یا HTTPS متصل میگردد.
اگر --socks4a چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --socks4a hostname:4096 https://example.com
این گزینه با --proxy، --socks4، --socks5 و --socks5-hostname مانعةالجمع است. همچنین --socks4، --socks5 و --socks5-hostname را ببینید.
- --socks5 <host[:port]>
- از پراکسی SOCKS5
مشخصشده
استفاده
کنید - اما
نام میزبان
را به صورت
محلی تحلیل
کنید. اگر
شماره پورت
مشخص نشده
باشد، پورت
1080 فرض
میشود.
برای تعیین پراکسی روی یک Unix domain socket، از localhost برای host استفاده کرده و مسیر مطلق سوکت دامنه را ضمیمه کنید. برای مثال: "socks5://localhost/path/to/socket.sock" (طرحواره یا scheme میتواند حذف شود).
این گزینه هرگونه استفاده قبلی از --proxy را لغو میکند، چرا که این گزینهها مانعةالجمع هستند.
این گزینه زائد است چرا که میتوانید با استفاده از یک پیشوند پروتکل "socks5://"، یک پراکسی socks5 را با --proxy مشخص کنید.
میتوان از --preproxy برای مشخص کردن یک پراکسی SOCKS همزمان با استفاده از --proxy به همراه یک پراکسی HTTP/HTTPS استفاده کرد. در چنین حالتی، curl ابتدا به پراکسی SOCKS وصل میشود و سپس (از طریق SOCKS) به پراکسی HTTP یا HTTPS متصل میگردد.
این گزینه با FTPS یا LDAP کار نمیکند.
اگر --socks5 چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثالها:
curl --socks5 proxy.example:7000 https://example.com curl --socks5 localhost/path/unix-domain https://example.com
این گزینه با --proxy، --socks4، --socks4a و --socks5-hostname مانعةالجمع است. همچنین --socks5-hostname و --socks4a را ببینید.
- --socks5-basic
- هنگام
اتصال به یک
پروکسی SOCKS5 از
احراز هویت
نام
کاربری/گذرواژه
استفاده
کنید. احراز
هویت نام
کاربری/گذرواژه
بهطور
پیشفرض
فعال است.
برای اجبار
احراز هویت
GSS-API در
پروکسیهای
SOCKS5 از --socks5-gssapi
استفاده
کنید.
مشخص کردن چندبارهٔ --socks5-basic اثر اضافهای ندارد.
مثال:
curl --socks5-basic --socks5 hostname:4096 https://example.com
همچنین --socks5 را ببینید.
- --socks5-gssapi
- (GSS/kerberos) هنگام
اتصال به یک
پروکسی SOCKS5 از
احراز هویت
GSS-API استفاده
کنید. احراز
هویت GSS-API
بهطور
پیشفرض
فعال است
(اگر curl با
پشتیبانی
از GSS-API
کامپایل
شده باشد).
برای اجبار
احراز هویت
نام
کاربری/گذرواژه
در
پروکسیهای
SOCKS5 از --socks5-basic
استفاده
کنید.
مشخص کردن چندبارهٔ --socks5-gssapi اثر اضافهای ندارد. با --no-socks5-gssapi دوباره آن را غیرفعال کنید.
مثال:
curl --socks5-gssapi --socks5 hostname:4096 https://example.com
همچنین --socks5 را ببینید.
- --socks5-gssapi-nec
- (GSS/kerberos)
بهعنوان
بخشی از
مذاکرهٔ GSS-API
یک حالت
حفاظت
مذاکره
میشود. سند
RFC 1961 در
بخشهای 4.3/4.4
میگوید که
باید
محافظت
شود، اما
پیادهسازی
مرجع NEC این
کار را
انجام
نمیدهد.
گزینهٔ
--socks5-gssapi-nec امکان
تبادل
محافظتنشدهٔ
مذاکرهٔ
حالت حفاظت
را فراهم
میکند.
مشخص کردن چندبارهٔ --socks5-gssapi-nec اثر اضافهای ندارد. با --no-socks5-gssapi-nec دوباره آن را غیرفعال کنید.
مثال:
curl --socks5-gssapi-nec --socks5 hostname:4096 https://example.com
همچنین --socks5 را ببینید.
- --socks5-gssapi-service <name>
- نام سرویس
را برای یک
سرور socks
تنظیم کنید.
مقدار
پیشفرض
rcmd/server-fqdn است.
اگر --socks5-gssapi-service چند بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --socks5-gssapi-service sockd --socks5 hostname:4096 https://example.com
همچنین --socks5 را ببینید.
- --socks5-hostname <host[:port]>
- از پروکسی SOCKS5
مشخصشده
استفاده
کنید (و
اجازه دهید
پروکسی نام
میزبان را
حل کند). اگر
شماره پورت
مشخص نشود،
پورت 1080 در
نظر گرفته
میشود.
برای تعیین پروکسی روی یک سوکت دامنه یونیکس، از localhost برای میزبان استفاده کرده و مسیر مطلق به سوکت دامنه را به آن اضافه کنید. برای مثال: "socks5h://localhost/path/to/socket.sock" (میتوان طرحواره را حذف کرد).
این گزینه هرگونه استفادهٔ قبلی از --proxy را لغو میکند، چرا که این دو مانعةالجمع هستند.
این گزینه زائد است چرا که میتوانید با استفاده از یک پیشوند پروتکل "socks5h://" در --proxy یک پروکسی socks5 با نام میزبان را مشخص کنید.
میتوان از --preproxy برای مشخص کردن یک پروکسی SOCKS همزمان با استفاده از --proxy برای یک پروکسی HTTP/HTTPS استفاده کرد. در چنین حالتی، curl ابتدا به پروکسی SOCKS متصل شده و سپس (از طریق SOCKS) به پروکسی HTTP یا HTTPS متصل میشود.
اگر --socks5-hostname چند بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --socks5-hostname proxy.example:7000 https://example.com
این گزینه با --proxy، --socks4، --socks4a و --socks5 مانعةالجمع است. همچنین --socks5 و --socks4a را ببینید.
- -Y, --speed-limit <speed>
- اگر یک
انتقال
برای تعداد
ثانیههای
مشخصی
کندتر از
این سرعت
تعیینشده
(بر حسب
بایت در
ثانیه)
باشد، لغو
میشود.
دورهٔ
زمانی با
--speed-time تنظیم
میشود و
بهطور
پیشفرض 30
ثانیه است.
اگر --speed-limit چند بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl --speed-limit 300 --speed-time 10 https://example.com
همچنین --speed-time، --limit-rate و --max-time را ببینید.
- -y, --speed-time <seconds>
- اگر سرعت یک
انتقال در
طول بازه
زمانی speed-time
کمتر از
مقدار بایت
بر ثانیه
تعیینشده
در speed-limit باشد،
انتقال
متوقف و لغو
میشود. اگر
speed-time استفاده
شود، مقدار
پیشفرض speed-limit
برابر ۱
خواهد بود
مگر اینکه
با --speed-limit
مقدار
دیگری
تعیین شده
باشد.
این گزینه سرعت انتقالها را در هر دو جهت مهار میکند اما تاثیری بر کندی در اتصال اولیه (اتصالهای کند) ندارد. اگر این موضوع برای شما اهمیت دارد، از گزینه --connect-timeout استفاده کنید.
اگر --speed-time چندین بار مشخص شود، آخرین مقدار اعمال خواهد شد.
مثال:
curl --speed-limit 300 --speed-time 10 https://example.com
همچنین ببینید: --speed-limit و --limit-rate.
- --ssl
- (FTP IMAP POP3 SMTP LDAP) هشدار:
این گزینه
ناامن تلقی
میشود. در
صورت امکان
از --ssl-reqd
استفاده
کنید تا
اطمینان
حاصل شود curl
اتصال را به
یک ارتباط
امن ارتقا
میدهد.
تلاش برای استفاده از SSL/TLS برای اتصال - معمولاً به دلیل دستورات مورد استفاده از آن با عنوان STARTTLS یا STLS یاد میشود. اگر سرور از SSL/TLS پشتیبانی نکند، اتصال به حالت غیرامن بازمیگردد. همچنین به --ftp-ssl-control و --ssl-reqd برای سطوح مختلف رمزنگاری مورد نیاز مراجعه کنید.
این گزینه در LDAP پشتیبانی میشود (اضافه شده در نسخه 7.81.0). این قابلیت در بکاند OpenLDAP کاملاً پشتیبانی شده اما در بکاند عمومی ldap نادیده گرفته میشود.
لطفاً توجه داشته باشید که اگر مذاکره امن ناموفق باشد، سرور ممکن است اتصال را ببندد.
در صورت تعیین شدن، این گزینه بر --ftp-ssl-control اولویت دارد.
این گزینه قبلاً با نام --ftp-ssl شناخته میشد. آن نام هنوز قابل استفاده است اما ممکن است در نسخههای آینده حذف شود.
استفاده چندباره از --ssl هیچ تاثیر مضاعفی ندارد. برای غیرفعال کردن مجدد آن از --no-ssl استفاده کنید.
مثال:
curl --ssl pop3://example.com
همچنین ببینید: --ssl-reqd، --insecure و --ciphers.
- --ssl-allow-beast
- (TLS) نقص
امنیتی
پروتکل TLS1.0
موسوم به BEAST
را دور
نزنید
(راهکار
اصلاحی را
اعمال
نکنید). اگر
از این
گزینه
استفاده
نشود، لایه
TLS ممکن است
از
راهکارهایی
استفاده
کند که مشخص
شده در برخی
پیادهسازیهای
قدیمی
سرورها
مشکلات
سازگاری
متقابل
ایجاد
میکند.
این گزینه فقط شیوه عملکرد TLS 1.0 در curl را تغییر میدهد و هیچ تاثیری بر نسخههای بالاتر TLS ندارد.
هشدار: این گزینه امنیت TLS را کاهش میدهد و با استفاده از این گزینه شما دقیقاً همین رفتار را درخواست میکنید.
استفاده چندباره از --ssl-allow-beast هیچ تاثیر مضاعفی ندارد. برای غیرفعال کردن مجدد آن از --no-ssl-allow-beast استفاده کنید.
مثال:
curl --ssl-allow-beast https://example.com
همچنین ببینید: --proxy-ssl-allow-beast و --insecure.
- --ssl-auto-client-cert
- (TLS) (Schannel) به طور
خودکار یک
گواهی
کلاینت را
برای احراز
هویت در
صورت
درخواست
سرور پیدا
کرده و
استفاده
میکند. از
آنجا که
سرور
میتواند
هر گواهی
دارای
پشتیبانی
از احراز
هویت
کلاینت در
مخزن گواهی
سیستمعامل
را درخواست
کند، این
امر ممکن
است نقض
حریم خصوصی
و
غیرمنتظره
باشد.
استفاده چندباره از --ssl-auto-client-cert هیچ تاثیر مضاعفی ندارد. برای غیرفعال کردن مجدد آن از --no-ssl-auto-client-cert استفاده کنید.
مثال:
curl --ssl-auto-client-cert https://example.com
اضافه شده در نسخه 7.77.0. همچنین ببینید: --proxy-ssl-auto-client-cert.
- --ssl-no-revoke
- (TLS) (Schannel) بررسی
ابطال
گواهی را
غیرفعال
میکند.
هشدار: این
گزینه
امنیت SSL را
کاهش
میدهد و با
استفاده از
این پرچم
شما دقیقاً
همین رفتار
را درخواست
میکنید.
استفاده چندباره از --ssl-no-revoke هیچ تاثیر مضاعفی ندارد. برای غیرفعال کردن مجدد آن از --no-ssl-no-revoke استفاده کنید.
مثال:
curl --ssl-no-revoke https://example.com
همچنین ببینید: --crlfile.
- --ssl-reqd
- (FTP IMAP POP3 SMTP LDAP) الزام
استفاده از
SSL/TLS برای
برقراری
اتصال - که
اغلب به
دلیل
دستورات
مربوطه به
آن STARTTLS یا STLS
گفته
میشود. در
صورتی که
نتوان
انتقال را
برای
استفاده از
SSL/TLS ارتقا
داد، اتصال
قطع میشود.
این گزینه در LDAP پشتیبانی میشود (اضافهشده در 7.81.0). این قابلیت بهطور کامل توسط بکاند OpenLDAP پشتیبانی شده و در صورت نیاز به TLS صریح (explicit)، توسط بکاند عمومی ldap رد میشود.
اگر از یک طرحواره URL استفاده کنید که خودبهخود متضمن استفاده فوری و ضمنی از TLS باشد، مانند FTPS، IMAPS، POP3S، SMTPS و LDAPS، این گزینه غیرضروری است. چنین انتقالی در صورتی که دستتکانی TLS ناموفق باشد، همواره با شکست مواجه میشود.
این گزینه پیشتر با عنوان --ftp-ssl-reqd شناخته میشد.
ارائه چندباره --ssl-reqd هیچ اثر اضافهای ندارد. با --no-ssl-reqd دوباره آن را غیرفعال کنید.
مثال:
curl --ssl-reqd ftp://example.com
همچنین --ssl و --insecure را ببینید.
- --ssl-revoke-best-effort
- (TLS) (Schannel) نادیده
گرفتن
بررسیهای
ابطال
گواهی،
هنگامی که
این
بررسیها
به دلیل
مفقود یا
آفلاین
بودن نقاط
توزیع
فهرستهای
بررسی
ابطال با
شکست مواجه
میشوند.
ارائه چندباره --ssl-revoke-best-effort هیچ اثر اضافهای ندارد. با --no-ssl-revoke-best-effort دوباره آن را غیرفعال کنید.
مثال:
curl --ssl-revoke-best-effort https://example.com
اضافهشده در 7.70.0. همچنین --crlfile و --insecure را ببینید.
- --ssl-sessions <filename>
- (TLS) **هشدار**:
این گزینه
آزمایشی
است. در
محیط
عملیاتی
استفاده
نکنید.
پیش از شروع هرگونه انتقال، از پرونده مشخصشده برای بارگذاری بلیتهای نشست SSL در حافظه پنهان curl استفاده کنید. در پایان یک اجرای موفقیتآمیز curl، بلیتهای ذخیرهشده نشست SSL در پرونده ذخیره میشوند و جایگزین هرگونه محتوای پیشین خواهند شد.
نیازی به وجود داشتن پرونده از قبل نیست، اما اگر curl قادر به ایجاد آن نباشد خطایی گزارش میدهد. بلیتهای بارگذاریشده استفادهنشده مجدداً ذخیره میشوند، مگر اینکه جایگزین شده یا به دلایل کمبود فضا از حافظه پنهان پاکسازی شوند.
استفاده از یک پرونده نشست به "--tls-earlydata" اجازه میدهد در صورت یافتن یک نشست SSL با این قابلیت، نخستین درخواست را در حالت "0-RTT" ارسال کند. توجه داشته باشید که ممکن است سرور از دادههای اولیه (early data) پشتیبانی نکند. همچنین توجه داشته باشید که دادههای اولیه، محرمانگی پیشرو (forward secrecy) فراهم نمیکنند، یعنی به همان اندازه امن نیستند.
بلیتهای نشست SSL بهصورت متن کدگذاریشده با base64 ذخیره میشوند و هر بلیت در خط مخصوص به خود قرار دارد. نامهای میزبان از نظر رمزنگاری سالتگذاری و هش میشوند. اگرچه این کار مانع از آن میشود که کسی بتواند بهراحتی میزبانهای مورد تماس شما را ببیند، اما همچنان میتوان بررسی کرد که آیا یک نام میزبان خاص با یکی از مقادیر مطابقت دارد یا خیر.
این ویژگی نیازمند آن است که libcurl زیرین با فعال بودن قابلیت آزمایشی درونریزی/برونریزی نشست SSL موسوم به (SSLS-EXPORT) ساخته شده باشد.
اگر --ssl-sessions چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --ssl-sessions sessions.txt https://example.com
اضافهشده در 8.12.0. همچنین --tls-earlydata را ببینید.
- -2, --sslv2
- (SSL) این گزینه
سابقاً از curl
میخواست
که از SSLv2
استفاده
کند، اما
اکنون
نادیده
گرفته
میشود
(اضافهشده
در 7.77.0). پروتکل
SSLv2 بهطور
گسترده
ناامن
دانسته
میشود (RFC 6176
را ببینید).
ارائه چندباره --sslv2 هیچ اثر اضافهای ندارد.
مثال:
curl --sslv2 https://example.com
برای اینکه --sslv2 کار کند، لازم است که libcurl زیرین برای پشتیبانی از TLS ساخته شده باشد. این گزینه با --sslv3، --tlsv1، --tlsv1.1 و --tlsv1.2 مانعةالجمع است. همچنین --http1.1 و --http2 را ببینید.
- -3, --sslv3
- (SSL) این گزینه
سابقاً از curl
میخواست
که از SSLv3
استفاده
کند، اما
اکنون
نادیده
گرفته
میشود
(اضافهشده
در 7.77.0). پروتکل
SSLv3 بهطور
گسترده
ناامن
دانسته
میشود (RFC 7568
را ببینید).
ارائه چندباره --sslv3 هیچ اثر اضافهای ندارد.
مثال:
curl --sslv3 https://example.com
برای اینکه --sslv3 کار کند، لازم است که libcurl زیرین برای پشتیبانی از TLS ساخته شده باشد. این گزینه با --sslv2، --tlsv1، --tlsv1.1 و --tlsv1.2 مانعةالجمع است. همچنین --http1.1 و --http2 را ببینید.
- --stderr <file>
- هدایت
تمامی
دادههای
ارسالی به stderr
به پرونده
مشخصشده
به جای آن.
اگر نام
پرونده
صرفاً یک '-'
باشد، به
جای آن در stdout
نوشته
میشود.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --stderr چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده خواهد شد.
مثال:
curl --stderr output.txt https://example.com
همچنین ببینید: --verbose و --silent.
- --styled-output
- فعالسازی
استفاده
خودکار از
قلم درشت (bold)
هنگام
نوشتن
سرآمدهای HTTP
در ترمینال.
برای خاموش
کردن آن از
--no-styled-output
استفاده
کنید.
خروجی قالببندیشده نیازمند ترمینالی است که از قلمهای درشت پشتیبانی کند. این ویژگی به دلیل فقدان این قابلیت، در curl برای Windows موجود نیست.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
ارائه چندباره --styled-output هیچ اثر اضافهای ندارد. آن را دوباره با --no-styled-output غیرفعال کنید.
مثال:
curl --styled-output -I https://example.com
همچنین ببینید: --head و --verbose.
- --suppress-connect-headers
- هنگامی که
از --proxytunnel
استفاده
میشود و یک
درخواست CONNECT
ارسال
میگردد،
سرآمدهای
پاسخ CONNECT
پروکسی را
در خروجی
نمایش
ندهید. این
گزینه برای
استفاده به
همراه --dump-header
یا --show-headers در
نظر گرفته
شده است که
برای نمایش
سرآمدهای
پروتکل در
خروجی
استفاده
میشوند.
این گزینه
هیچ اثری
روی
گزینههای
اشکالزدایی
مانند --verbose یا
--trace یا
هرگونه
آمار دیگری
ندارد.
ارائه چندباره --suppress-connect-headers هیچ اثر اضافهای ندارد. آن را دوباره با --no-suppress-connect-headers غیرفعال کنید.
مثال:
curl --suppress-connect-headers --show-headers -x proxy https://example.com
همچنین ببینید: --dump-header، --show-headers و --proxytunnel.
- --tcp-fastopen
- استفاده از
TCP Fast Open (RFC 7413) را فعال
میکند.
افزونه TCP Fast Open
یکی از
قابلیتهای
TCP است که در
صورت اتصال
قبلی
کلاینت و
سرور،
امکان
ارسال
زودهنگام
دادهها را
روی اتصال
(پیش از ACK
نهایی
دستتکانی)
فراهم
میسازد.
ارائه چندباره --tcp-fastopen هیچ اثر اضافهای ندارد. آن را دوباره با --no-tcp-fastopen غیرفعال کنید.
مثال:
curl --tcp-fastopen https://example.com
همچنین ببینید: --false-start.
- --tcp-nodelay
- گزینه TCP_NODELAY را
فعال
میکند.
این گزینه الگوریتم Nagle را در اتصالات TCP غیرفعال میکند. هدف این الگوریتم به حداقل رساندن تعداد بستههای کوچک در شبکه است (که منظور از «بستههای کوچک»، قطعههای (segments) TCP با اندازه کمتر از Maximum Segment Size برای شبکه است).
به حداکثر رساندن مقدار داده ارسالی در هر سگمنت TCP سودمند است زیرا سربار ارسال را سرشکن میکند. در برخی موارد ممکن است ارسال قطعههای کوچک بدون تأخیر ضروری باشد. این کار نسبت به ارسال مقادیر بیشتر داده در یک زمان، کارایی کمتری دارد و در صورت زیادهروی میتواند به ازدحام در شبکه بینجامد.
ابزار curl این گزینه را به طور پیشفرض فعال میکند و اگر مایل به فعال بودن آن نیستید، باید آن را به طور صریح خاموش کنید.
ارائه چندباره --tcp-nodelay هیچ اثر اضافهای ندارد. آن را دوباره با --no-tcp-nodelay غیرفعال کنید.
مثال:
curl --tcp-nodelay https://example.com
همچنین ببینید: --no-buffer.
- -t, --telnet-option <opt=val>
- (TELNET) ارسال گزینهها به پروتکل telnet. گزینههای پشتیبانیشده عبارتند از:
- TTYPE=<term>
- نوع ترمینال را تنظیم میکند.
- XDISPLOC=<X display>
- محل نمایشگر X را تنظیم میکند.
- NEW_ENV=<var,val>
- یک متغیر محیطی را تنظیم میکند.
-
از --telnet-option میتوان چندین بار در خط فرمان استفاده کرد.
مثال:
curl -t TTYPE=vt100 telnet://example.com
همچنین ببینید: --config.
- --tftp-blksize <value>
- (TFTP) گزینه BLKSIZE
در TFTP را
تنظیم
میکند
(باید ۵۱۲
یا بزرگتر
باشد). این
اندازه
بلوکی است
که curl هنگام
انتقال
داده به یا
از یک سرور TFTP
تلاش
میکند از
آن استفاده
کند. بهطور
پیشفرض
۵۱۲ بایت
استفاده
میشود.
اگر --tftp-blksize چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --tftp-blksize 1024 tftp://example.com/file
همچنین ببینید: --tftp-no-options.
- --tftp-no-options
- (TFTP)
درخواستهای
گزینههای
TFTP را ارسال
نمیکند.
این کار
سازگاری با
برخی
سرورهای
قدیمی را که
گزینههای
TFTP را تأیید
نکرده یا به
درستی
پیادهسازی
نمیکنند،
بهبود
میبخشد.
هنگامی که
این گزینه
استفاده
شود، --tftp-blksize
نادیده
گرفته
میشود.
مشخص کردن چندباره --tftp-no-options اثر اضافهای ندارد. با --no-tftp-no-options دوباره آن را غیرفعال کنید.
مثال:
curl --tftp-no-options tftp://192.168.0.1
همچنین ببینید: --tftp-blksize.
- -z, --time-cond <time>
- (HTTP FTP)
پروندهای
را درخواست
میکند که
پس از زمان
و تاریخ
ارائهشده
ویرایش شده
باشد، یا
پروندهای
که پیش از
آن زمان
ویرایش شده
است. عبارت
تاریخ
میتواند
انواع
رشتههای
تاریخ باشد
یا اگر با
هیچیک از
موارد
داخلی
مطابقت
نداشته
باشد، به
عنوان نام
یک پرونده
در نظر
گرفته
میشود و curl
در عوض سعی
میکند
تاریخ
ویرایش (mtime) را
از آن
پرونده
دریافت کند.
برای
جزئیات
عبارت
تاریخ،
صفحه
راهنمای
curl_getdate(3) را
ببینید.
عبارت تاریخ را با یک خط تیره (-) شروع کنید تا سندی را درخواست کند که قدیمیتر از تاریخ/زمان ارائهشده است؛ حالت پیشفرض سندی است که جدیدتر از تاریخ/زمان مشخصشده باشد.
اگر پروندهای ارائه شود که وجود ندارد، curl هشداری درباره این موضوع نمایش میدهد و بدون شرط زمانی به انجام انتقال ادامه میدهد.
اگر --time-cond چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl -z "Wed 01 Sep 2021 12:18:00" https://example.com curl -z "-Wed 01 Sep 2021 12:18:00" https://example.com curl -z file https://example.com
همچنین ببینید: --etag-compare و --remote-time.
- --tls-earlydata
- (TLS) استفاده
از
دادههای
اولیه (early data) در
TLSv1.3 را، که در
صورت امکان
با عنوان '0RTT'
نیز شناخته
میشود،
فعال
میکند. این
کار
پیامدهای
امنیتی
برای
درخواستهایی
دارد که از
این طریق
ارسال
میشوند.
این گزینه زمانی میتواند استفاده شود که curl برای استفاده از GnuTLS ،OpenSSL ،quictls و wolfSSL به عنوان ارائهدهنده TLS ساخته شده باشد (اما نه AWS-LC ،BoringSSL یا Rustls).
پشتیبانی یک سرور از این ویژگی TLSv1.3 و میزان آن، به عنوان بخشی از «نشست» TLS که به curl بازگردانده میشود اعلان میگردد. تا زمانی که curl چنین نشستی را در یک درخواست قبلی ندیده باشد، دادههای اولیه قابل استفاده نیستند.
هنگامی که یک اتصال جدید با یک نشست شناختهشده TLSv1.3 برقرار میشود و آن نشست پشتیبانی از دادههای اولیه را اعلام کرده باشد، نخستین درخواست در این اتصال پیش از تکمیل دستتکانی (handshake) پروتکل TLS ارسال میشود. با اینکه دادههای اولیه نیز رمزگذاری میشوند، در برابر حملات بازپخش (replay) محافظت نمیشوند. یک مهاجم میتواند دادههای اولیه شما را دوباره به سرور ارسال کند و سرور آن را بپذیرد.
اگر درخواست شما با یک سرور عمومی ارتباط برقرار کند و تنها یک پرونده را دریافت کند، ممکن است آسیبی نداشته باشد. اگر درخواست نخست برای شما یک یخچال سفارش میدهد، احتمالاً ایده خوبی نیست که برای آن از دادههای اولیه استفاده کنید. curl نمیتواند پیامدهای امنیتی واقعی درخواستهای شما را استنتاج کند و این تصمیم را به جای شما بگیرد.
میزان دادههای اولیه ارسالشده را میتوان با استفاده از متغیر "tls_earlydata" در "--write-out" بررسی کرد.
هشدار: این گزینه پیامدهای امنیتی دارد. برای جزئیات بیشتر به موارد بالا مراجعه کنید.
مشخص کردن چندباره --tls-earlydata اثر اضافهای ندارد. با --no-tls-earlydata دوباره آن را غیرفعال کنید.
مثال:
curl --tls-earlydata https://example.com
اضافهشده در 8.11.0. همچنین ببینید: --tlsv1.3، --tls-max و --ssl-sessions.
- --tls-max <VERSION>
- (TLS) حداکثر
نسخه مجاز TLS
را تنظیم
میکند.
حداقل نسخه
قابل قبول
توسط tlsv1.0، tlsv1.1، tlsv1.2
یا tlsv1.3 تعیین
میشود.
اگر اتصال بدون TLS برقرار شود، این گزینه هیچ اثری ندارد. این شامل انتقالهای مبتنی بر QUIC (HTTP/3) نیز میشود.
- default
- استفاده حداکثر تا نسخه توصیهشده TLS.
- 1.0
- استفاده حداکثر تا TLSv1.0.
- 1.1
- استفاده حداکثر تا TLSv1.1.
- 1.2
- استفاده حداکثر تا TLSv1.2.
- 1.3
- استفاده حداکثر تا TLSv1.3.
-
اگر --tls-max چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثالها:
curl --tls-max 1.2 https://example.com curl --tls-max 1.3 --tlsv1.2 https://example.com
برای کارکرد --tls-max، لازم است که libcurl زیرین برای پشتیبانی از TLS ساخته شده باشد. همچنین ببینید: --tlsv1.0، --tlsv1.1، --tlsv1.2 و --tlsv1.3.
- --tls13-ciphers <list>
- (TLS) تعیین
میکند در
صورت
مذاکره TLS 1.3 در
اتصال، از
کدام
مجموعههای
رمز (cipher suites)
استفاده
شود. فهرست
مجموعههای
رمز باید
رمزهای
معتبری را
مشخص کند.
جزئیات
بیشتر
درباره
مجموعههای
رمز TLS 1.3 را در
این نشانی
بخوانید:
https://curl.se/docs/ssl-ciphers.html
این گزینه زمانی استفاده میشود که curl برای استفاده از OpenSSL نسخه 1.1.1 یا جدیدتر، wolfSSL یا mbedTLS نسخه 3.6.0 یا جدیدتر ساخته شده باشد.
پیش از curl 8.10.0 به همراه mbedTLS یا wolfSSL، مجموعههای رمز TLS 1.3 با استفاده از گزینه --ciphers تنظیم میشدند.
اگر --tls13-ciphers چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --tls13-ciphers TLS_AES_128_GCM_SHA256 https://example.com
همچنین ببینید: --ciphers، --proxy-tls13-ciphers و --curves.
- --tlsauthtype <type>
- (TLS) گزینه
منسوخشده.
این گزینه
از نسخه 8.22.0
هیچ
عملکردی
ندارد.
نوع احراز هویت TLS را تعیین میکند. در حال حاضر، تنها گزینه پشتیبانیشده "SRP" است، برای TLS-SRP (RFC 5054). اگر --tlsuser و --tlspassword مشخص شده باشند ولی --tlsauthtype مشخص نشده باشد، این گزینه به صورت پیشفرض بر روی "SRP" قرار میگیرد. این گزینه تنها در صورتی کار میکند که libcurl زیرین با پشتیبانی از TLS-SRP ساخته شده باشد، که نیازمند OpenSSL یا GnuTLS با پشتیبانی از TLS-SRP است.
اگر --tlsauthtype چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --tlsauthtype SRP https://example.com
همچنین ببینید: --tlsuser.
- --tlspassword <string>
- (TLS) گزینه
منسوخشده.
این گزینه
از نسخه 8.22.0
هیچ
عملکردی
ندارد.
گذرواژه مورد استفاده با روش احراز هویت TLS مشخصشده با --tlsauthtype را تنظیم میکند. نیازمند این است که --tlsuser تنظیم شده باشد.
این گزینه با TLS 1.3 کار نمیکند.
اگر --tlspassword چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --tlspassword pwd --tlsuser user https://example.com
همچنین ببینید: --tlsuser.
- --tlsuser <name>
- (TLS) گزینه
منسوخشده.
این گزینه
از نسخه 8.22.0
هیچ
عملکردی
ندارد.
نام کاربری مورد استفاده با روش احراز هویت TLS مشخصشده با --tlsauthtype را تنظیم میکند. نیازمند این است که --tlspassword نیز تنظیم شده باشد.
این گزینه با TLS 1.3 کار نمیکند.
اگر --tlsuser چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --tlspassword pwd --tlsuser user https://example.com
همچنین ببینید: --tlspassword.
- -1, --tlsv1
- (TLS) هنگام
مذاکره با
یک سرور
دوردست TLS،
دستکم از
نسخهٔ 1.x
پروتکل TLS
استفاده
میکند. این
به معنای
نسخهٔ 1.0 یا
بالاتر TLS
است.
ارائه دادن چندبارهٔ --tlsv1 تأثیر اضافهای ندارد.
مثال:
curl --tlsv1 https://example.com
برای کارکرد --tlsv1، لازم است که libcurl زیرین با پشتیبانی از TLS ساخته شده باشد. این گزینه با --tlsv1.1، --tlsv1.2 و --tlsv1.3 مانعةالجمع است. همچنین --http1.1 و --http2 را ببینید.
- --tlsv1.0
- (TLS) هنگام
اتصال به یک
سرور
دوردست TLS،
ابزار curl را
مجبور
میکند از
نسخهٔ 1.0 یا
بالاتر TLS
استفاده
کند.
در نسخههای قدیمی curl این گزینه به عنوان مجاز دانستن _تنها_ TLS 1.0 مستند شده بود. آن رفتار بسته به کتابخانهٔ TLS ناهماهنگ بود. اگر میخواهید بیشینهٔ نسخهٔ TLS را تعیین کنید، از --tls-max استفاده کنید.
ارائه دادن چندبارهٔ --tlsv1.0 تأثیر اضافهای ندارد.
مثال:
curl --tlsv1.0 https://example.com
همچنین --tlsv1.3 را ببینید.
- --tlsv1.1
- (TLS) هنگام
اتصال به یک
سرور
دوردست TLS،
ابزار curl را
مجبور
میکند از
نسخهٔ 1.1 یا
بالاتر TLS
استفاده
کند.
در نسخههای قدیمی curl این گزینه به عنوان مجاز دانستن _تنها_ TLS 1.1 مستند شده بود. آن رفتار بسته به کتابخانهٔ TLS ناهماهنگ بود. اگر میخواهید بیشینهٔ نسخهٔ TLS را تعیین کنید، از --tls-max استفاده کنید.
ارائه دادن چندبارهٔ --tlsv1.1 تأثیر اضافهای ندارد.
مثال:
curl --tlsv1.1 https://example.com
همچنین --tlsv1.3 و --tls-max را ببینید.
- --tlsv1.2
- (TLS) هنگام
اتصال به یک
سرور
دوردست TLS،
ابزار curl را
مجبور
میکند از
نسخهٔ 1.2 یا
بالاتر TLS
استفاده
کند.
در نسخههای قدیمی curl این گزینه به عنوان مجاز دانستن _تنها_ TLS 1.2 مستند شده بود. آن رفتار بسته به کتابخانهٔ TLS ناهماهنگ بود. اگر میخواهید بیشینهٔ نسخهٔ TLS را تعیین کنید، از --tls-max استفاده کنید.
ارائه دادن چندبارهٔ --tlsv1.2 تأثیر اضافهای ندارد.
مثال:
curl --tlsv1.2 https://example.com
همچنین --tlsv1.3 و --tls-max را ببینید.
- --tlsv1.3
- (TLS) هنگام
اتصال به یک
سرور
دوردست TLS،
ابزار curl را
مجبور
میکند از
نسخهٔ 1.3 یا
بالاتر TLS
استفاده
کند.
اگر اتصال بدون TLS انجام شود، این گزینه هیچ تأثیری ندارد. این شامل انتقالهای مبتنی بر QUIC (HTTP/3) نیز میشود.
توجه داشته باشید که TLS 1.3 توسط همهٔ پساندهای TLS پشتیبانی نمیشود.
ارائه دادن چندبارهٔ --tlsv1.3 تأثیر اضافهای ندارد.
مثال:
curl --tlsv1.3 https://example.com
همچنین --tlsv1.2 و --tls-max را ببینید.
- --tr-encoding
- (HTTP) یک پاسخ
فشردهشدهٔ
Transfer-Encoding را با
استفاده از
یکی از
الگوریتمهایی
که curl
پشتیبانی
میکند
درخواست
کرده، و
دادهها را
هنگام
دریافت از
حالت فشرده
خارج
میکند.
این روش زمانی قرار بود راهکاری برای فشردهسازی خودکار دادهها در HTTP باشد، اما از هر نظر عملی، استفاده از Content-Encoding همانطور که با --compressed انجام میشود جایگزین transfer encoding شده است. بنابراین گزینهٔ --tr-encoding اغلب آن چیزی نیست که میخواهید.
ارائه دادن چندبارهٔ --tr-encoding تأثیر اضافهای ندارد. با --no-tr-encoding دوباره آن را غیرفعال کنید.
مثال:
curl --tr-encoding https://example.com
همچنین --compressed را ببینید.
- --trace <file>
- ذخیرهٔ یک
رونوشت
کامل
ردگیری از
تمامی
دادههای
ورودی و
خروجی،
شامل
اطلاعات
توصیفی، در
پروندهٔ
خروجی
مشخصشده.
از "-"
بهعنوان
نام پرونده
استفاده
کنید تا
خروجی به stdout
فرستاده
شود. از "%"
بهعنوان
نام پرونده
استفاده
کنید تا
خروجی به stderr
فرستاده
شود.
توجه داشته باشید که خروجی پرگو (verbose) از فعالیتهای curl و ترافیک شبکه ممکن است حاوی دادههای حساس، از جمله نامهای کاربری، اطلاعات اعتبارسنجی یا محتوای دادههای محرمانه باشد. هنگام بهاشتراکگذاری گزارشهای ردگیری با دیگران، آگاه و مراقب باشید.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --trace چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --trace log.txt https://example.com
این گزینه با --verbose و --trace-ascii مانعةالجمع است. همچنین --trace-ascii، --trace-config، --trace-ids و --trace-time را ببینید.
- --trace-ascii <file>
- ذخیرهٔ یک
رونوشت
کامل
ردگیری از
تمامی
دادههای
ورودی و
خروجی،
شامل
اطلاعات
توصیفی، در
پروندهٔ
خروجی
مشخصشده.
از "-"
بهعنوان
نام پرونده
استفاده
کنید تا
خروجی به stdout
فرستاده
شود. از "%"
بهعنوان
نام پرونده
استفاده
کنید تا
خروجی به stderr
ارسال شود.
این گزینه مشابه --trace است، اما بخش هگزادسیمال (hex) را حذف کرده و فقط بخش ASCII رونوشت را نمایش میدهد. این امر خروجی کوچکتری تولید میکند که خواندن آن برای افراد غیرمتخصص میتواند آسانتر باشد.
توجه داشته باشید که خروجی پرگو (verbose) از فعالیتهای curl و ترافیک شبکه ممکن است حاوی دادههای حساس، از جمله نامهای کاربری، اطلاعات اعتبارسنجی یا محتوای دادههای محرمانه باشد. هنگام بهاشتراکگذاری گزارشهای ردگیری با دیگران، آگاه و مراقب باشید.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
اگر --trace-ascii چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --trace-ascii log.txt https://example.com
این گزینه با --trace و --verbose مانعةالجمع است. همچنین --verbose و --trace را ببینید.
- --trace-config <string>
- تنظیم
پیکربندی
برای خروجی
ردگیری.
فهرستی
جداشده با
ویرگول از
مؤلفههایی
که خروجی
باجزئیات
میتواند
از آنها
فراهم شود.
نامها به
بزرگی و
کوچکی حروف
حساس
نیستند.
برای
فعالکردن
همهٔ
مؤلفههای
ردگیری، 'all'
را مشخص
کنید.
علاوه بر نام مؤلفههای ردگیری، "ids" و "time" را مشخص کنید تا از پارامترهای اضافی --trace-ids یا --trace-time جلوگیری شود.
برای جزئیات بیشتر صفحهٔ راهنمای curl_global_trace(3) را ببینید.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
--trace-config میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --trace-config ids,http/2 https://example.com
در نسخهٔ 8.3.0 اضافه شد. همچنین --verbose و --trace را ببینید.
- --trace-ids
- شناسههای
انتقال و
اتصال را به
ابتدای هر
خط ردگیری
یا پرگویی
(verbose) که curl نمایش
میدهد،
اضافه
میکند.
شناسهها شمارههای یکتایی هستند که به هر اتصال و انتقال اختصاص داده میشوند تا به کاربر امکان دهند بهتر متوجه شود هر خط خروجی پرگو به کدام انتقال و اتصال اشاره دارد.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
مشخصکردن چندینبارهٔ --trace-ids هیچ تأثیر اضافهای ندارد. با --no-trace-ids دوباره آن را غیرفعال کنید.
مثال:
curl --trace-ids --trace-ascii output https://example.com
در نسخهٔ 8.2.0 اضافه شد. همچنین --trace و --verbose را ببینید.
- --trace-time
- یک برچسب
زمانی را به
ابتدای هر
خط ردگیری
یا پرگویی
(verbose) که curl نمایش
میدهد،
اضافه
میکند.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
مشخصکردن چندینبارهٔ --trace-time هیچ تأثیر اضافهای ندارد. با --no-trace-time دوباره آن را غیرفعال کنید.
مثال:
curl --trace-time --trace-ascii output https://example.com
همچنین --trace و --verbose را ببینید.
- --unix-socket <path>
- (HTTP) اتصال به
سرور از
طریق این
سوکت دامنه
یونیکس،
بهجای
استفاده از
شبکه.
برای اتصال به یک پروکسی از طریق سوکت دامنه یونیکس، --proxy را ببینید.
اگر --unix-socket چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --unix-socket socket-path https://example.com
همچنین --abstract-unix-socket را ببینید.
- -T, --upload-file <file>
- بارگذاری
پرونده
محلی
مشخصشده
در URL دوردست.
اگر در URL مشخصشده بخشی برای نام پرونده وجود نداشته باشد، curl پیش از شروع عملیات، نام پرونده محلی را به انتهای URL الصاق میکند. باید یک اسلش پایانی ("/") در انتهای آخرین دایرکتوری قرار دهید تا برای curl مشخص شود که نام پروندهای وجود ندارد، در غیر این صورت curl تصور میکند نام آخرین دایرکتوری شما همان نام پرونده دوردست است که باید استفاده شود.
هنگام قرار دادن نام پرونده محلی در انتهای URL، curl آنچه را که در سمت چپ هر اسلش ("/") یا بکاسلش ("\\") استفادهشده در نام پرونده باشد نادیده میگیرد و تنها آنچه را در سمت راستِ راستترین نویسه از این دست قرار دارد الصاق میکند.
از نام پرونده "-" (یک خط تیره تکی) برای استفاده از stdin بهجای پرونده مشخصشده استفاده کنید. به طور متناوب، میتوان نام پرونده "." (یک نقطه تکی) را بهجای "-" مشخص کرد تا از stdin در حالت غیرمسدودکننده (non-blocking) استفاده شود و خواندن خروجی سرور در حین بارگذاری stdin امکانپذیر باشد.
اگر این گزینه با یک URL از نوع HTTP(S) استفاده شود، از متد PUT استفاده میشود.
میتوانید به ازای هر URL در خط فرمان، یک --upload-file مشخص کنید. هر جفت --upload-file + URL مشخص میکند چه چیزی و به کجا بارگذاری شود. همچنین curl از الگوخوانی (globbing) برای آرگومان --upload-file پشتیبانی میکند؛ به این معنی که میتوانید با استفاده از همان سبک globbing پشتیبانیشده در URL، چندین پرونده را در یک URL واحد بارگذاری کنید. مثال:
curl --upload-file 'file{1,2,3}' ftp://ftp.example/از نسخه 8.21.0 به بعد curl، هنگامی که از globbing استفاده میشود، میتوانید با تنظیم یک نام برای glob و ارجاع به آن به همان شیوهای که به globهای نامدارِ URL ارجاع میدهید، از بخشهایی از نام پرونده بارگذاری استفاده کنید. برای مثال، اگر سه پرونده را در یک URL ثابت HTTP بارگذاری میکنید و میخواهید پاسخهای متناظر را در پروندههای جداگانه ذخیره کنید:
curl -T 'file{<num>1,2,3}' \ https://upload.example/ -o 'response-#<num>'هنگام بارگذاری در سرور SMTP (یا همان «ارسال ایمیل»): فرض میشود که دادههای بارگذاریشده دارای قالب RFC 5322 هستند. این دادهها باید شامل سرآیندهای لازم و بدنه نامهای باشند که توسط کاربر به درستی قالببندی شدهاند، زیرا curl به هیچ وجه آنها را بازکدگذاری یا مجدداً کدگذاری نمیکند.
گزینه --upload-file با یک URL واحد مرتبط است. هنگامی که از چندین URL در یک خط فرمان استفاده میکنید، برای هر URL یک بار از آن استفاده کنید.
مثالها:
curl -T file https://example.com curl -T "img[1-1000].png" ftp://ftp.example.com/ curl --upload-file "{file1,file2}" https://example.com curl -T file -T file2 https://example.com https://example.comهمچنین --get، --head، --request و --data را ببینید.
- --upload-flags <flags>
- (IMAP) رفتار
اضافی برای
اعمال روی
پروندههای
بارگذاریشده
را مشخص
میکند.
پرچمها یا
به صورت یک
مقدار پرچم
تکی یا
فهرستی از
مقادیر
پرچم
جداشده با
کاما مشخص
میشوند.
این مقادیر
به بزرگی و
کوچکی حروف
حساس هستند
و میتوان
با قرار
دادن نویسه
'-' در ابتدای
آنها،
آنها را
نفی کرد. در
حال حاضر
مقادیر
پرچم زیر
پذیرفته
میشوند: answered،
deleted، draft، flagged و seen.
مقادیر
پرچم
پذیرفتهشده
کنونی برای
تنظیم
پرچمها
روی
بارگذاریهای
IMAP استفاده
میشوند.
اگر --upload-flags چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --upload-flags Flagged,!Seen --upload-file local/dir/file https://example.com
در نسخه 8.13.0 اضافه شد. همچنین --upload-file را ببینید.
- --url <url/file>
- یک URL را برای
واکشی یا
ارسال داده
به آن مشخص
میکند.
اگر URL دادهشده فاقد طرحواره (مانند "http://" یا "ftp://" و غیره) باشد، curl بر اساس نام میزبان حدس میزند که از کدام طرحواره استفاده کند. اگر بیرونیترین نام زیردامنه بدون توجه به بزرگی و کوچکی حروف با DICT، FTP، IMAP، LDAP، POP3 یا SMTP مطابقت داشته باشد، آن پروتکل استفاده میشود؛ در غیر این صورت HTTP فرض میشود. میتوان با ارائه یک URL کامل شامل طرحواره از حدس زدن طرحواره جلوگیری کرد، یا با تنظیم یک پروتکل پیشفرض آن را غیرفعال نمود؛ برای جزئیات، --proto-default را ببینید.
برای کنترل این که محتوای یک URL دریافتشده بهجای stdout پیشفرض در کجا نوشته شود، از گزینههای --output یا --remote-name استفاده کنید. هنگام دریافت چندین URL در یک فراخوانی واحد، هر URL ارائهشده به گزینه مقصد اختصاصی خود نیاز دارد، مگر اینکه از --remote-name-all استفاده شود.
در ویندوز، دسترسیهای "file://" میتوانند توسط سیستمعامل به دسترسیهای شبکه تبدیل شوند.
از نسخه 8.13.0 به بعد curl، میتوان به curl گفت که URLهای ارائهشده در یک پرونده متنی را، هر خط یک URL، بارگیری کند. این کار با "--url @filename" انجام میشود: بنابراین بهجای یک URL، نام پروندهای را با پیشوند نماد "@" مشخص میکنید. همچنین با ارائه آرگومانی مانند "@-" میتوان به آن دستور داد تا فهرست URLها را از stdin بارگذاری کند.
هنگام بارگیری URLهای ارائهشده در یک پرونده، این کار به معنای استفاده ضمنی از --remote-name برای هر URL ارائهشده است. این URLها کامل هستند و هیچ globbing روی آنها اعمال یا انجام نمیشود. ویژگیهایی مانند --skip-existing به خوبی در ترکیب با این قابلیت کار میکنند.
خطوطی از پرونده URL که با "#" آغاز میشوند به عنوان توضیح در نظر گرفته شده و نادیده گرفته میشوند.
--url میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl --url https://example.com curl --url @file
همچنین --next، --config، --path-as-is و --disallow-username-in-url را ببینید.
- --url-query <data>
- افزودن یک
قطعه داده،
معمولاً یک
جفت نام +
مقدار، به
انتهای بخش
query از URL. نحو آن
کاملاً
مشابه نحو
مورد
استفاده
برای --data-urlencode
است، همراه
با یک
قابلیت
اضافه:
اگر آرگومان با یک '+' (بهعلاوه) شروع شود، باقی رشته همانطور که هست و بدون کدگذاری ارسال میشود.
بخش query در یک URL، بخشی است که پس از علامت سؤال در سمت راست قرار میگیرد.
گزینهٔ --url-query میتواند چندین بار در یک خط فرمان استفاده شود.
مثالها:
curl --url-query name=val https://example.com curl --url-query =encodethis http://example.net/foo curl --url-query name@file https://example.com curl --url-query @fileonly https://example.com curl --url-query "+name=%20foo" https://example.com
در نسخه 7.87.0 اضافه شد. همچنین --data-urlencode و --get را ببینید.
- -B, --use-ascii
- (FTP LDAP TFTP)
فعالسازی
حالت
انتقال ASCII.
برای FTP، این
کار همچنین
میتواند
با استفاده
از یک URL که با
";type=A" پایان
مییابد
اعمال شود.
برای TFTP، این
کار همچنین
میتواند
با استفاده
از یک URL که با
";mode=netascii" پایان
مییابد
اعمال شود.
این گزینه
در
سیستمهای
Win32 باعث
میشود
دادههای
ارسالشده
به stdout در حالت
متنی (text mode)
باشند.
استفادهٔ چندباره از --use-ascii تأثیر مضاعفی ندارد. آن را مجدداً با --no-use-ascii غیرفعال کنید.
مثال:
curl -B ftp://example.com/README
همچنین --crlf و --data-ascii را ببینید.
- -u, --user <user:password>
- مشخص کردن
نام کاربری
و گذرواژه
برای احراز
هویت در
سرور. بر --netrc و
--netrc-optional اولویت
دارد.
اگر فقط نام کاربری را مشخص کنید، curl گذرواژه را درخواست میکند.
نام کاربری و گذرواژه در محل نخستین دونقطه (colon) از یکدیگر تفکیک میشوند، که باعث میشود با این گزینه نتوان از دونقطه در نام کاربری استفاده کرد. با این حال، گذرواژه همچنان میتواند دونقطه داشته باشد.
در سیستمهایی که از این ویژگی پشتیبانی میکنند، curl آرگومان ارائهشده برای گزینه را از فهرست فرایندها (process listings) پنهان میکند. این کار برای محافظت از اطلاعات احراز هویت در برابر دیدهشدن احتمالی توسط دیگر کاربران در همان سیستم کافی نیست، زیرا این اطلاعات پیش از پاکشدن همچنان برای لحظهای قابل مشاهده هستند. چنین دادههای حساسی را در عوض باید از یک فایل یا روشهای مشابه دریافت کرد و هرگز نباید بهصورت متن آشکار (clear text) در خط فرمان استفاده شوند.
هنگام استفاده از Kerberos V5 با یک سرور مبتنی بر Windows، باید نام دامنهٔ Windows را در نام کاربری بگنجانید تا سرور بتواند یک بلیت کربروس (Kerberos Ticket) را با موفقیت دریافت کند. اگر این کار را نکنید، دستتکانی اولیهٔ احراز هویت ممکن است ناموفق باشد.
هنگام استفاده از NTLM، اگر برای نمونه تنها یک دامنه و بیشه (forest) در پیکربندی شما وجود داشته باشد، نام کاربری میتواند بدون دامنه مشخص شود.
برای تعیین نام دامنه از قالبهای Down-Level Logon Name یا UPN (User Principal Name) استفاده کنید. برای نمونه، به ترتیب: EXAMPLE\user و user@example.com.
اگر از فایل باینری curl با پشتیبانی از Windows SSPI استفاده میکنید و احراز هویت Kerberos V5، Negotiate، NTLM یا Digest را انجام میدهید، میتوانید با مشخص کردن تنها یک علامت دونقطه برای این گزینه: "-u :"، به curl بگویید نام کاربری و گذرواژه را از متغیرهای محیطی شما انتخاب کند.
اگر --user چندین بار ارائه شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl -u user:secret https://example.com
همچنین --netrc و --config را ببینید.
- -A, --user-agent <name>
- (HTTP) رشتهٔ User-Agent
را برای
ارسال به
سرور HTTP مشخص
میکند.
برای
کدگذاری
فاصلههای
خالی در
رشته، آن را
در میان
علامتهای
نقلقول
تکی یا جفتی
قرار دهید.
این سربرگ
همچنین
میتواند
با
گزینههای
--header یا --proxy-header
تنظیم شود.
اگر یک آرگومان خالی به --user-agent بدهید ("")، این سربرگ را بهطور کامل از درخواست حذف میکند. اگر ترجیح میدهید سربرگی خالی داشته باشید، میتوانید آن را روی یک فاصله خالی (" ") تنظیم کنید.
بهطور پیشفرض، curl از curl/VERSION استفاده میکند، مانند User-Agent: curl/8.22.0.
اگر --user-agent چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl -A "Agent 007" https://example.com
همچنین --header و --proxy-header را ببینید.
- --variable <[%]name=text/@file>
- یک متغیر را
با "name=content" یا
"name@file" تنظیم
میکند (که
در آن در
صورت تنظیم
روی یک خط
تیره منفرد
("-")، "file"
میتواند stdin
باشد). نام
متغیر
شناسهای
حساس به
حروف کوچک و
بزرگ است که
نباید از
حروفی به جز
a-z، A-Z، 0-9 یا خط
زیر (underscore)
تشکیل شده
باشد. سپس
محتوای
مشخصشده
با این
شناسه
مرتبط
میشود.
تنظیم مجدد همان نام متغیر، محتوای قدیمی را با محتوای جدید بازنویسی میکند.
محتوای یک متغیر میتواند در یک گزینه بعدی خط فرمان مورد ارجاع قرار گیرد، در صورتی که نام آن گزینه با پیشوند "--expand-" همراه باشد و از نام به صورت "{{name}}" استفاده شود.
--variable میتواند متغیرهای محیطی را وارد فضای نام کند. میتوانید تعیین کنید که متغیر محیطی حتماً تنظیم شده باشد، یا در صورتی که از قبل تنظیم نشده باشد، یک مقدار پیشفرض برای متغیر ارائه دهید.
--variable %name متغیری به نام "name" را وارد میکند اما اگر آن متغیر محیطی از قبل تنظیم نشده باشد، با یک خطا خارج میشود. برای ارائه یک مقدار پیشفرض در صورت تنظیم نبودن متغیر محیطی، از --variable %name=content یا --variable %name@content استفاده کنید. توجه داشته باشید که در برخی سیستمها - اما نه همه - متغیرهای محیطی به حروف کوچک و بزرگ حساس نیستند.
افزودهشده در curl 8.12.0: با افزودن "[start-end]" به نام متغیر، میتوانید یک محدوده بایتی از منبع دریافت کنید، که در آن start و end آفستهای بایتی برای گنجاندن از محتوا هستند. به عنوان مثال، درخواست آفست "2-10" به معنای آفست دو تا آفست ده، شامل هر دو، است که در مجموع ۹ بایت را نتیجه میدهد. "2-2" به معنای یک بایت منفرد در آفست ۲ است. ارائه ندادن عدد دوم به معنای ادامه تا انتهای داده است. آفست شروع نمیتواند بزرگتر از آفست پایان باشد. درخواست محدودهای که خارج از اندازه پرونده باشد، محتوای متغیر را خالی میکند. برای مثال، دریافت صد بایت نخست از یک پرونده مشخص:
curl --variable "fraction[0-99]@filename"
تعیین یک محدوده بایتی که فاقد داده باشد منجر به یک رشته خالی میشود. درخواست محدودهای بزرگتر از محتوا باعث میشود curl از بخشی از داده که وجود دارد استفاده کند.
برای مقداردهی یک متغیر با استفاده از محتوای یک متغیر دیگر، از --expand-variable استفاده کنید. مانند اختصاص دادن یک متغیر جدید با استفاده از محتوای دو متغیر دیگر:
curl --expand-variable "user={{firstname}} {{lastname}}"هنگام بسط متغیرها، curl از مجموعهای از توابع پشتیبانی میکند که استفاده از محتوای متغیر را آسانتر میسازند. شما میتوانید با افزودن یک دونقطه و سپس ذکر توابع مورد نظر در یک فهرست جداشده با کاما که به ترتیب چپ به راست ارزیابی میشود، تابعی را روی بسط متغیر اعمال کنید. محتوای متغیری که حاوی بایتهای null باشد و هنگام بسط کدگذاری نشده باشد، خطایی ایجاد میکند.
توابع موجود:
- trim
- تمام
فاصلههای
سفید ابتدا
و انتها را
حذف میکند.
مثال:
curl --expand-url https://example.com/{{var:trim}} - json
- محتوا را با
استفاده از
قواعد
نقلقول
رشته در JSON
خروجی
میدهد.
مثال:
curl --expand-data {{data:json}} https://example.com - url
- محتوا را به
صورت
کدگذاریشده
برای URL
(کدگذاری
درصدی)
نمایش
میدهد.
مثال:
curl --expand-url https://example.com/{{path:url}} - b64
- متغیر را به
صورت
کدگذاریشده
با base64 بسط
میدهد
مثال:
curl --expand-url https://example.com/{{var:b64}} - 64dec
- یک دنباله
نویسهای
کدگذاریشده
با base64 را
رمزگشایی
میکند. اگر
رمزگشایی
دنباله
ممکن
نباشد، در
عوض "[64dec-fail]" را
خروجی
میدهد
مثال:
curl --expand-url https://example.com/{{var:64dec}}(افزودهشده در 8.13.0)
-
--variable میتواند چندین بار در یک خط فرمان استفاده شود.
مثال:
curl --variable name=smith --expand-url "https://example.com/{{name}}"در 8.3.0 افزوده شد. همچنین ببینید --config.
- -v, --verbose
- باعث میشود curl اطلاعات مشروح را در طول عملیات در خروجی نمایش دهد. برای اشکالزدایی و دیدن آنچه در پشت صحنه میگذرد مفید است. خطوط خروجی مشروح با حروفی پیشوندگذاری میشوند:
- >
- سرآیند ارسالشده توسط curl
- <
- سرآیند دریافتشده توسط curl
- }
- داده ارسالشده توسط curl
- {
- داده دریافتشده توسط curl
- *
- اطلاعات اضافی ارائهشده توسط curl. متنی که توضیحاتی درباره آنچه رخ میدهد و انتخابهایی که curl انجام میدهد میافزاید.
- اگر فقط
سرآیندهای
HTTP را در
خروجی
میخواهید،
--show-headers یا --dump-header
ممکن است
گزینههای
مناسبتری
باشند.
از curl 8.10 به بعد، ذکر چندینباره این گزینه در همان آرگومان سطح خروجی ردگیری را افزایش میدهد. مانند قبل، یک --verbose یا --no-verbose منفرد دوباره تمام موارد اضافهشده توسط "-vv" قبلی را لغو میکند. این بدان معناست که "-vv -v" معادل یک -v منفرد است. این امر از خروجی مشروح ناخواسته در زمانی که گزینه در خط فرمان و فایلهای پیکربندی curl ذکر شده باشد جلوگیری میکند.
استفاده دو باره از آن، مثلاً "-vv"، زمان (--trace-time) و شناسههای انتقال (--trace-ids) را خروجی میدهد و همچنین ردگیری را برای تمام پروتکلها فعال میکند (--trace-config protocol).
افزودن سومین verbose محتوای انتقال را خروجی میدهد (--trace-ascii %) و ردگیری مؤلفههای بیشتری را فعال میسازد (--trace-config read,write,ssl).
بار چهارم ردگیری تمام مؤلفههای شبکه را اضافه میکند. (--trace-config network).
هرگونه افزودن گزینه verbose پس از آن هیچ اثری ندارد.
اگر فکر میکنید این گزینه جزئیات مناسب را به شما ارائه نمیدهد، استفاده از --trace یا --trace-ascii را به جای آن در نظر بگیرید. یا فقط یک بار از آن استفاده کنید و از --trace-config برای ردگیری مؤلفههای خاصی که مایل به دیدنشان هستید بهره ببرید.
توجه داشته باشید که خروجی مشروح فعالیتهای curl و ترافیک شبکه ممکن است شامل دادههای حساس، از جمله نامهای کاربری، اطلاعات اعتبارسنجی یا محتوای دادههای محرمانه باشد. هنگام بهاشتراکگذاری گزارشهای ردگیری با دیگران، آگاه و مراقب باشید.
هنگامی که خروجی حاوی سرآیندهای پروتکل است، آن خطوط ممکن است شامل نویسههای بازگشت به ابتدای سطر (کد اسکی ۱۳) باشند، حتی در پلتفرمهایی که در حالت عادی معمولاً فقط از linefeed برای نشان دادن جداسازی خطوط استفاده میکنند - چرا که curl محتوای دقیقی را که از سرور میرسد نمایش میدهد.
این گزینه سراسری است و نیازی نیست برای هر بار استفاده از --next مشخص شود.
ارائه چندباره --verbose هیچ تأثیر اضافی ندارد. آن را دوباره با --no-verbose غیرفعال کنید.
مثال:
curl --verbose https://example.com
این گزینه با --trace و --trace-ascii مانعةالجمع است. همچنین ببینید --show-headers، --silent، --trace و --trace-ascii.
- -V, --version
- نمایش
اطلاعات
درباره curl و
نسخه libcurl که
استفاده
میکند.
خط اول شامل نسخه کامل curl، libcurl و سایر کتابخانههای شخص ثالث پیوند داده شده با فایل اجرایی است.
این خط ممکن است شامل یک یا چند کتابخانه TLS باشد. curl میتواند بهگونهای ساخته شود که از بیش از یک کتابخانه TLS پشتیبانی کند که در این صورت curl - در هنگام راهاندازی - انتخاب میکند که از کدام بکاند خاص برای این فراخوانی استفاده شود.
اگر curl بدین صورت از بیش از یک کتابخانه TLS پشتیبانی کند، مواردی که بهطور پیشفرض انتخاب نشدهاند در پرانتز فهرست میشوند. بنابراین، اگر مشخص نکنید که از کدام بکاند استفاده شود (با متغیر محیطی "CURL_SSL_BACKEND")، موردی که بدون پرانتز فهرست شده است استفاده میشود. چنین ساختهایی همچنین ویژگی "MultiSSL" را فعال دارند.
خط دوم (که با "Release-Date:" آغاز میشود) تاریخ انتشار را نشان میدهد.
خط سوم (که با "Protocols:" آغاز میشود) همه پروتکلهایی را نشان میدهد که libcurl پشتیبانی از آنها را گزارش میدهد.
خط چهارم (که با "Features:" آغاز میشود) ویژگیهای خاصی را نشان میدهد که libcurl ارائه آنها را گزارش میدهد. ویژگیهای موجود عبارتند از:
- alt-svc
- پشتیبانی از سرآیند Alt-Svc: فراهم شده است.
- AsynchDNS
- این curl از تحلیل ناهمگام نام استفاده میکند. تحلیل ناهمگام نام میتواند با استفاده از هر یک از بکاندهای c-ares یا حلکننده ریسهای انجام شود.
- brotli
- پشتیبانی از فشردهسازی خودکار brotli از طریق HTTP(S).
- CharConv
- curl با پشتیبانی از تبدیل مجموعه نویسهها (مانند EBCDIC) ساخته شده است
- Debug
- این curl از یک libcurl ساختهشده با قابلیت Debug استفاده میکند. این مورد ردیابی خطای بیشتر و اشکالزدایی حافظه و غیره را فعال میکند. فقط برای توسعهدهندگان curl.
- ECH
- پشتیبانی از ECH وجود دارد.
- gsasl
- احراز هویت توکار SASL شامل افزونههایی برای پشتیبانی از SCRAM است زیرا libcurl با libgsasl ساخته شده است.
- GSS-API
- از GSS-API پشتیبانی میشود.
- HSTS
- پشتیبانی از HSTS وجود دارد.
- HTTP2
- پشتیبانی از HTTP/2 به صورت توکار گنجانده شده است.
- HTTP3
- پشتیبانی از HTTP/3 به صورت توکار گنجانده شده است.
- HTTPS-proxy
- این curl برای پشتیبانی از پروکسی HTTPS ساخته شده است.
- IDN
- این curl از IDN - نامهای بینالمللی دامنه پشتیبانی میکند.
- IPv6
- میتوانید با این از IPv6 استفاده کنید.
- Kerberos
- از احراز هویت Kerberos V5 پشتیبانی میشود.
- Largefile
- این curl از انتقال پروندههای بزرگ، یعنی پروندههای بزرگتر از 2GB پشتیبانی میکند.
- libz
- از فشردهزدایی خودکار (از طریق gzip، deflate) پروندههای فشردهشده روی HTTP پشتیبانی میشود.
- MultiSSL
- این curl از چندین بکاند TLS پشتیبانی میکند.
- NTLM
- از احراز هویت NTLM پشتیبانی میشود.
- NTLM_WB
- از واگذاری NTLM به دستیار winbind پشتیبانی میشود. این قابلیت در نسخه 8.8.0 از curl حذف شد.
- PSL
- PSL مخفف Public Suffix List است و بدان معناست که این curl با آگاهی از "پسوندهای عمومی" ساخته شده است.
- SPNEGO
- از احراز هویت SPNEGO پشتیبانی میشود.
- SSL
- از نسخههای SSL پروتکلهای مختلف، مانند HTTPS، FTPS، POP3S و غیره پشتیبانی میشود.
- SSLS-EXPORT
- این ساخت از برونریزی/درونریزی نشست TLS پشتیبانی میکند، مانند گزینه --ssl-sessions.
- SSPI
- از SSPI پشتیبانی میشود.
- Unicode
- پشتیبانی از یونیکد در Windows.
- UnixSockets
- پشتیبانی از سوکتهای یونیکس فراهم شده است.
- zstd
- از فشردهزدایی خودکار (از طریق zstd) پروندههای فشردهشده روی HTTP پشتیبانی میشود.
-
مثال:
curl --version
همچنین --help و --manual را ببینید.
- --vlan-priority <priority>
- اولویت VLAN را
همانطور
که در IEEE 802.1Q
تعریف شده
است تنظیم
کنید.
این فیلد در لایه Ethernet تنظیم میشود و تنها درون یک شبکه محلی کار میکند.
محدوده معتبر برای <priority> از 0 تا 7 است.
اگر --vlan-priority چندین بار مشخص شود، آخرین مقدار تنظیمشده استفاده میشود.
مثال:
curl --vlan-priority 4 https://example.com
در 8.9.0 اضافه شد. همچنین --ip-tos را ببینید.
- -w, --write-out <format>
- باعث میشود
curl پس از
پایان
انتقال،
اطلاعاتی
را روی stdout
نمایش دهد.
قالب یک
رشته متنی
است که
میتواند
حاوی متن
ساده
آمیخته با
هر تعداد
متغیر باشد.
قالب را
میتوان به
صورت یک
"رشته"
لغوی تعیین
کرد، یا
میتوان
کاری کرد که
curl قالب را با
"@filename" از یک
پرونده
بخواند و
برای اینکه
به curl بگویید
قالب را از stdin
بخواند، "@-"
را
مینویسید.
متغیرهای موجود در قالب خروجی، مطابق با توضیحات زیر با مقدار یا متنی که curl مناسب تشخیص میدهد جایگزین میشوند. تمام متغیرها به صورت %{variable_name} مشخص میشوند و برای خروجی دادن یک % معمولی، آنها را به صورت %% مینویسید. میتوانید با استفاده از \n یک خط جدید، با \r یک بازگشت به ابتدای سطر و با \t یک فاصله برگه خروجی دهید.
خروجی به طور پیشفرض در خروجی استاندارد نوشته میشود، اما میتوان آن را با %{stderr} و %output{} تغییر داد.
با استفاده از %header{name} مقادیر سرآیند HTTP را از تازهترین پاسخ سرور در انتقال خروجی دهید؛ جایی که name نام غیرحساس به بزرگی و کوچکی حروف سرآیند است (بدون دونقطه پایانی). محتوای سرآیند دقیقاً همان چیزی است که روی شبکه ارسال شده است، اما فاصلههای خالی و خطوط جدید ابتدا و انتهای آن حذف شدهاند (در 7.84.0 اضافه شد).
با استفاده از %output{name} (در curl 8.3.0 اضافه شد) که در آن name نام کامل پرونده است، یک پرونده مقصد مشخص را برای نوشتن خروجی انتخاب کنید. خروجیِ پیرو آن دستورالعمل، سپس در آن پرونده نوشته خواهد شد. بیش از یک دستورالعمل %output{} را میتوان در همان آرگومان write-out تعیین کرد. اگر پرونده نتواند ایجاد شود، curl مقصد خروجی را همان مقصدی باقی میگذارد که قبل از دستورالعمل %output{} استفاده شده بود. از %output{>>name} برای الحاق دادهها به یک پرونده موجود استفاده کنید.
این خروجی مستقل از موفقیتآمیز بودن یا نبودن انتقال پرونده انجام میشود.
اگر اقدام مشخصشده یا خروجی تعیینشده با این گزینه به هر نحوی با شکست مواجه شود، باعث نمیشود که curl خطای (متفاوتی) برگرداند.
نکته: در Windows، نماد %- یک نماد ویژه است که برای بسط متغیرهای محیطی استفاده میشود. در پروندههای دستهای (batch files)، هنگام استفاده از این گزینه، تمام تکرارهای % باید دو بار تکرار شوند تا به درستی گریز داده شوند. اگر از این گزینه در خط فرمان استفاده شود، آنگاه % نمیتواند گریز داده شود و امکان بسط ناخواسته وجود دارد.
متغیرهای در دسترس عبارتند از:
- certs
- زنجیره گواهی را همراه با جزئیات خروجی میدهد. تنها توسط بکاندهای OpenSSL، GnuTLS، Schannel و Rustls پشتیبانی میشود. (افزوده شده در 7.88.0)
- conn_id
- شناسه اتصالی که آخرین بار توسط انتقال استفاده شد. شناسه اتصال یک شماره یکتا در میان تمام اتصالاتی است که از یک حافظه پنهان اتصال مشترک استفاده میکنند. (افزوده شده در 8.2.0)
- content_type
- مقدار Content-Type سند درخواستی، در صورت وجود داشتن.
- errormsg
- پیام خطا. (افزوده شده در 7.75.0)
- exitcode
- کد خروج عددی انتقال. (افزوده شده در 7.75.0)
- filename_effective
- نام پرونده نهایی که curl در آن مینویسد. این مقدار تنها زمانی معنادار است که به curl با گزینه --remote-name یا --output گفته شده باشد که در یک پرونده بنویسد. بیشترین کاربرد آن در ترکیب با گزینه --remote-header-name است.
- ftp_entry_path
- مسیر اولیهای که curl هنگام ورود به سرور دوردست FTP در آن قرار گرفت.
- header{name}
- مقدار
سرآیند "name"
از واپسین
پاسخ سرور
در انتقال.
برخلاف
متغیرهای
دیگر، نام
متغیر "header"
درون
آکولاد
قرار
نمیگیرد.
برای نمونه
"%header{date}". به
توضیحات
--write-out مراجعه
کنید.
(افزوده شده
در 7.84.0)
از نسخه 8.17.0 به بعد، خروجی دادن محتوای همه فیلدهای سرآیند با یک نام مشخص - حتی برای یک "زنجیره" کامل تغییرمسیر - با الحاق ":all:[separator]" به نام سرآیند انجام میشود. رشته "[separator]" (در صورت خالی نبودن) اگر بیش از یک سرآیند وجود داشته باشد، میان سرآیندها چاپ میشود. هنگامی که بیش از یک سرآیند نمایش داده میشود، آنها به ترتیب زمانی دریافت روی خط خروجی داده میشوند. برای گنجاندن یک آکولاد بسته ("}") در جداکننده، آن را با یک بکاسلش گریز دهید: "\}".
- header_json
- یک شیء JSON
شامل تمامی
سرآیندهای
پاسخ HTTP از
انتقال
اخیر.
مقادیر
بهصورت
آرایه
ارائه
میشوند،
چرا که در
صورت وجود
چند سرآیند
ممکن است
چندین
مقدار وجود
داشته باشد.
(افزوده شده
در 7.83.0)
نامهای سرآیند با حروف کوچک ارائه شده و به ترتیب دریافت روی خط فهرست میشوند. بهجز سرآیندهای تکراری؛ آنها در اولین رخداد آن سرآیند گروهبندی میشوند و هر مقدار در آرایه JSON نمایش داده میشود.
- http_code
- کد پاسخ عددی که در آخرین انتقال بازیابیشده HTTP(S) یا FTP(s) یافت شد.
- http_connect
- کد عددی که در آخرین پاسخ (از سوی یک پروکسی) به درخواست CONNECT در curl یافت شد.
- http_version
- نسخه http که در عمل استفاده شده است.
- json
- یک شیء JSON شامل تمامی کلیدهای موجود بهجز "header_json". (افزوده شده در 7.70.0)
- local_ip
- نشانی IP سمت محلی آخرین اتصال انجامشده - میتواند IPv4 یا IPv6 باشد.
- local_port
- شماره درگاه محلی آخرین اتصال انجامشده.
- method
- روش http استفادهشده در آخرین درخواست HTTP. (افزوده شده در 7.72.0)
- num_certs
- تعداد گواهیهای سرور دریافتشده در دستتکانی TLS. تنها توسط بکاندهای OpenSSL، GnuTLS، Schannel و Rustls پشتیبانی میشود. (افزوده شده در 7.88.0)
- num_connects
- تعداد اتصالات جدید برقرارشده در انتقال اخیر.
- num_headers
- تعداد سرآیندهای پاسخ در آخرین درخواست (در هر تغییرمسیر مجدداً از نو شمارش میشود). توجه داشته باشید که خط وضعیت یک سرآیند نیست. (افزوده شده در 7.73.0)
- num_redirects
- تعداد تغییرمسیرهایی که در درخواست دنبال شدند.
- num_retries
- تعداد تلاشهای مجددی که در عمل هنگام استفاده از "--retry" انجام شده است. (افزوده شده در 8.9.0)
- onerror
- بقیه خروجی تنها در صورتی نمایش داده میشود که انتقال، خطایی غیرصفر بازگردانده باشد. (افزوده شده در 7.75.0)
- output{filename}
- از این نقطه به بعد، خروجی --write-out در نام پرونده مشخصشده درون آکولاد نوشته میشود. میتوان پیشوند ">>" را به نام پرونده افزود تا به انتهای پرونده الحاق شود. برخلاف سایر متغیرها، نام متغیر "output" درون آکولاد قرار نمیگیرد. برای نمونه "%output{>>stats.txt}". به نکات --write-out مراجعه کنید. (افزوده شده در 8.3.0)
- proxy_ssl_verify_result
- نتیجه اعتبارسنجی گواهی همتای SSL پروکسی HTTPS که درخواست شده بود. مقدار 0 به معنای موفقیتآمیز بودن اعتبارسنجی است.
- proxy_used
- اگر انتقال قبلی از پروکسی استفاده کرده باشد مقدار 1 و در غیر این صورت 0 برمیگرداند. برای نمونه جهت تشخیص اینکه آیا یک الگوی "NOPROXY" با نام میزبان مطابقت داشته است یا خیر مفید است. (افزوده شده در 8.7.0)
- redirect_url
- هنگامی که یک درخواست HTTP بدون --location برای دنبال کردن تغییرمسیرها ارسال شده باشد (یا زمانی که به سقف --max-redirs رسیده باشد)، این متغیر URL واقعی را نشان میدهد که تغییرمسیر به آن منتقل میشد.
- referer
- سرآیند Referer:، در صورتی که وجود داشته باشد. (افزوده شده در 7.76.0)
- remote_ip
- نشانی IP راه دور برای آخرین اتصال برقرار شده - میتواند IPv4 یا IPv6 باشد.
- remote_port
- شماره پورت راه دور برای آخرین اتصال برقرار شده.
- response_code
- کد پاسخ عددی که در آخرین انتقال یافت شد (پیشتر با عنوان "http_code" شناخته میشد).
- scheme
- طرحواره URL (گاهی پروتکل نامیده میشود) که عملاً استفاده شده است.
- size_delivered
- مقدار کل دادهای که ذخیره شده یا در stdout نوشته شده است. هنگامی که --compressed استفاده شود، این مقدار احتمالاً با "size_download" متفاوت است. در صورت استفاده از --include، سرآیندها نیز در شمارش لحاظ میشوند.
- size_download
- تعداد کل بایتهای دانلود شده. این اندازه بدنه/داده منتقل شده بدون احتساب سرآیندها است.
- size_header
- تعداد کل بایتهای سرآیندهای دانلود شده، همانگونه که در قالب سرآیند HTTP/1-style نشان داده شده است.
- size_request
- تعداد کل بایتهایی که در درخواست HTTP ارسال شدهاند.
- size_upload
- تعداد کل بایتهای آپلود شده. این اندازه بدنه/داده منتقل شده بدون احتساب سرآیندها است.
- speed_download
- میانگین سرعت دانلودی که curl برای کل دانلود اندازهگیری کرده است. بایت بر ثانیه.
- speed_upload
- میانگین سرعت آپلودی که curl برای کل آپلود اندازهگیری کرده است. بایت بر ثانیه.
- ssl_verify_result
- نتیجه اعتبارسنجی گواهی همتای SSL که درخواست شده بود. عدد 0 به این معنی است که اعتبارسنجی موفقیتآمیز بوده است.
- stderr
- از این نقطه به بعد، خروجی --write-out در خطای استاندارد نوشته میشود.
- stdout
- از این نقطه به بعد، خروجی --write-out در خروجی استاندارد نوشته میشود. این حالت پیشفرض است، اما پس از تغییر به stderr میتواند برای بازگشت استفاده شود.
- time{format}
- خروجی دادن زمان جاری UTC با استفاده از قالب "strftime()". برای جزئیات به TIME OUTPUT FORMAT در زیر مراجعه کنید. (افزوده شده در 8.16.0)
- time_appconnect
- مدت زمانی، به ثانیه، که از ابتدا تا تکمیل اتصال/دستتکانی SSL/SSH/غیره با میزبان راه دور سپری شد.
- time_connect
- مدت زمانی، به ثانیه، که از ابتدا تا تکمیل اتصال TCP به میزبان راه دور (یا پروکسی) سپری شد.
- time_namelookup
- مدت زمانی، به ثانیه، که از ابتدا تا تکمیل تفکیک نام سپری شد.
- time_posttransfer
- مدت زمانی، به ثانیه، که از ابتدا تا ارسال آخرین بایت توسط libcurl سپری شد. (افزوده شده در 8.10.0)
- time_pretransfer
- مدت زمانی، به ثانیه، که از ابتدا تا درست پیش از آغاز انتقال پرونده سپری شد. این شامل تمامی دستورات پیشازانتقال و مذاکراتی است که مختص پروتکل(های) دخیل هستند.
- time_queue
- مدت زمانی، به ثانیه، که انتقال در طول اجرای خود در صف قرار گرفت. این مقدار، زمان صف را برای هر مرحله تغییرمسیر که ممکن است رخ داده باشد اضافه میکند. هنگامی که محدودیتهای اتصال یا همزمانی برقرار باشد، ممکن است انتقالها برای مدت زمان قابلتوجهی در صف بمانند. (افزوده شده در 8.12.0)
- time_redirect
- مدت زمانی، به ثانیه، که برای تمام مراحل تغییرمسیر شامل تفکیک نام، اتصال، پیشانتقال و انتقال پیش از آغاز تراکنش نهایی طول کشید. "time_redirect" کل زمان اجرا را برای چندین تغییرمسیر نشان میدهد.
- time_starttransfer
- مدت زمانی، به ثانیه، که از ابتدا تا دریافت اولین بایت سپری شد. این شامل time_pretransfer و همچنین زمانی است که سرور برای محاسبه نتیجه نیاز داشت.
- time_total
- کل مدت زمانی، به ثانیه، که کل عملیات به طول انجامید.
- tls_earlydata
- تعداد بایتهایی که به عنوان داده اولیه TLSv1.3 ارسال شدند. اگر این قابلیت TLS استفاده نشده باشد این مقدار 0 است، و اگر داده ارسالشده توسط سرور رد شده باشد منفی خواهد بود. استفاده از داده اولیه از طریق گزینه خط فرمان "--tls-earlydata" فعال میشود. (افزوده شده در 8.13.0)
- url
- نشانی URL که واکشی شد. (افزوده شده در 7.75.0)
- url.scheme
- بخش طرحواره از نشانی URL که واکشی شد. (افزوده شده در 8.1.0)
- url.user
- بخش کاربری از نشانی URL که واکشی شد. (افزوده شده در 8.1.0)
- url.password
- بخش گذرواژه از نشانی URL که واکشی شد. (افزوده شده در 8.1.0)
- url.options
- بخش گزینهها (options) از URL واکشیشده. (افزودهشده در 8.1.0)
- url.host
- بخش میزبان (host) از URL واکشیشده. (افزودهشده در 8.1.0)
- url.port
- شماره پورت URL واکشیشده. اگر هیچ شماره پورتی مشخص نشده باشد و طرحواره (scheme) URL شناختهشده باشد، شماره پورت پیشفرض آن طرحواره نشان داده میشود. (افزودهشده در 8.1.0)
- url.path
- بخش مسیر (path) از URL واکشیشده. (افزودهشده در 8.1.0)
- url.query
- بخش پرسوجو (query) از URL واکشیشده. (افزودهشده در 8.1.0)
- url.fragment
- بخش قطعه (fragment) از URL واکشیشده. (افزودهشده در 8.1.0)
- url.zoneid
- بخش شناسه منطقه (zone id) از URL واکشیشده. (افزودهشده در 8.1.0)
- urle.scheme
- بخش طرحواره (scheme) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.user
- بخش کاربر (user) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.password
- بخش گذرواژه (password) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.options
- بخش گزینهها (options) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.host
- بخش میزبان (host) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.port
- شماره پورت URL مؤثر (آخرین) واکشیشده. اگر هیچ شماره پورتی مشخص نشده باشد، اما طرحواره (scheme) URL شناختهشده باشد، شماره پورت پیشفرض آن طرحواره نشان داده میشود. (افزودهشده در 8.1.0)
- urle.path
- بخش مسیر (path) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.query
- بخش پرسوجو (query) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.fragment
- بخش قطعه (fragment) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urle.zoneid
- بخش شناسه منطقه (zone id) از URL مؤثر (آخرین) واکشیشده. (افزودهشده در 8.1.0)
- urlnum
- شماره نمایه URL این انتقال، 0-indexed. نشانیهای URL بسطیافته (unglobbed) شماره نمایه یکسانی با URL دارای الگوی مبدأ (globbed) دارند. (افزودهشده در 7.75.0)
- url_effective
- آخرین URL واکشیشده. این مورد بیشترین کاربرد را زمانی دارد که به curl گفته باشید سرآیندهای location: را دنبال کند.
- xfer_id
- شناسه عددی آخرین انتقال انجامشده. اگر هنوز هیچ انتقالی برای این دستگیره (handle) آغاز نشده باشد، -1 است. شناسه انتقال (transfer id) در میان تمام انتقالهای انجامشده با استفاده از یک حافظه موقت اتصال (connection cache) یکتا است. (افزودهشده در 8.2.0)
- قالب خروجی
زمان (TIME OUTPUT FORMAT)
برای نمایش زمان با "%time{}"، نویسههای درون "{}" یک رشته قالب ویژه ایجاد میکنند که میتواند شامل توالیهای نویسهای خاصی به نام مشخصات تبدیل (conversion specifications) باشد. هر مشخصه تبدیل با "%" شروع میشود و پس از آن نویسهای میآید که به curl دستور میدهد جزئیات زمانی خاصی را نمایش دهد. تمام نویسههای دیگر به همان شکل (as-is) نمایش داده میشوند.
مشخصات تبدیل زیر در دسترس هستند:
- %a
- نام اختصاری روز هفته بر اساس locale فعلی.
- %A
- نام کامل روز هفته بر اساس locale فعلی.
- %b
- نام اختصاری ماه بر اساس locale فعلی.
- %B
- نام کامل ماه بر اساس locale فعلی.
- %c
- نمایش ترجیحی تاریخ و زمان برای locale فعلی. (در locale استاندارد POSIX این معادل "%a %b %e %H:%M:%S %Y" است.)
- %C
- شماره قرن (year/100) به صورت یک عدد صحیح 2-رقمی.
- %d
- روز ماه به صورت یک عدد دهدهی (در محدوده 01 تا 31).
- %D
- معادل "%m/%d/%y". در زمینههای بینالمللی، این قالب مبهم است و باید از آن اجتناب شود.)
- %e
- مانند "%d"، روز ماه به صورت یک عدد دهدهی، اما صفر ابتدایی با یک فاصله جایگزین میشود.
- %f
- تعداد میکروثانیههای سپریشده از ثانیه جاری. (این یک کد اختصاصی curl است و استاندارد نیست.)
- %F
- معادل "%Y-%m-%d" (قالب تاریخ ISO 8601).
- %G
- سال مبتنی بر هفته (week-based) استاندارد ISO 8601 به همراه قرن به صورت یک عدد دهدهی. سال 4-رقمی متناظر با شماره هفته ISO (ببینید "%V"). این همان قالب و مقدار "%Y" را دارد، جز اینکه اگر شماره هفته ISO متعلق به سال قبلی یا بعدی باشد، آن سال به جای آن استفاده میشود.
- %g
- مانند "%G"، اما بدون سده، یعنی با یک سال ۲ رقمی (00-99).
- %h
- معادل "%b".
- %H
- ساعت بهصورت یک عدد دهدهی با استفاده از ساعت ۲۴ ساعته (محدوده 00 تا 23).
- %I
- ساعت بهصورت یک عدد دهدهی با استفاده از ساعت ۱۲ ساعته (محدوده 01 تا 12).
- %j
- روز سال بهصورت یک عدد دهدهی (محدوده 001 تا 366).
- %k
- ساعت (ساعت ۲۴ ساعته) بهصورت یک عدد دهدهی (محدوده 0 تا 23)؛ پیش از اعداد تکرقمی یک فاصله خالی قرار میگیرد.
- %l
- ساعت (ساعت ۱۲ ساعته) بهصورت یک عدد دهدهی (محدوده 1 تا 12)؛ پیش از اعداد تکرقمی یک فاصله خالی قرار میگیرد.
- %m
- ماه بهصورت یک عدد دهدهی (محدوده 01 تا 12).
- %M
- دقیقه بهصورت یک عدد دهدهی (محدوده 00 تا 59).
- %p
- بسته به مقدار زمان دادهشده، "AM" یا "PM"، یا رشتههای متناظر برای لوکال فعلی. ظهر بهصورت "PM" و نیمهشب بهصورت "AM" در نظر گرفته میشود.
- %P
- مانند "%p" اما با حروف کوچک: "am" یا "pm" یا رشته متناظر برای لوکال فعلی.
- %r
- زمان در قالب am یا pm.
- %R
- زمان در قالب ۲۴ ساعته ("%H:%M"). برای نسخهای که شامل ثانیهها باشد، "%T" در زیر را ببینید.
- %s
- تعداد ثانیههای سپریشده از Epoch، یعنی 1970-01-01 00:00:00 +0000 (UTC).
- %S
- ثانیه بهصورت یک عدد دهدهی (محدوده 00 تا 60). (محدوده تا 60 است تا امکان ثانیههای کبیسه گاهبهگاه فراهم باشد.) برای میکروثانیهها "%f" را ببینید.
- %T
- زمان در قالب ۲۴ ساعته ("%H:%M:%S").
- %u
- روز هفته بهصورت یک عدد دهدهی، محدوده 1 تا 7، که دوشنبه برابر 1 است.
- %U
- شماره هفته سال جاری بهصورت یک عدد دهدهی، محدوده 00 تا 53، با شروع از اولین یکشنبه بهعنوان نخستین روز هفته 01. همچنین "%V" و "%W" را ببینید.
- %V
- شماره هفته سال جاری بر اساس ISO 8601 (بخش NOTES را ببینید) بهصورت یک عدد دهدهی، محدوده 01 تا 53، که در آن هفته ۱ نخستین هفتهای است که دستکم ۴ روز در سال جدید دارد. همچنین "%U" و "%W" را ببینید.
- %w
- روز هفته بهصورت یک عدد دهدهی، محدوده 0 تا 6، که یکشنبه برابر 0 است. همچنین "%u" را ببینید.
- %W
- شماره هفته سال جاری بهصورت یک عدد دهدهی، محدوده 00 تا 53، با شروع از اولین دوشنبه بهعنوان نخستین روز هفته 01.
- %x
- نمایش ترجیحی تاریخ برای لوکال فعلی بدون زمان.
- %X
- نمایش ترجیحی زمان برای لوکال فعلی بدون تاریخ.
- %y
- سال بهصورت یک عدد دهدهی بدون سده (محدوده 00 تا 99).
- %Y
- سال بهصورت یک عدد دهدهی شامل سده.
- %z
- منطقه زمانی عددی "+hhmm" یا "-hhmm" (یعنی اختلاف ساعت و دقیقه از UTC). از آنجا که زمان همیشه UTC است، این مقدار "+0000" را خروجی میدهد.
- %Z
- نام منطقه زمانی. بنا به دلایلی "GMT".
- %%
- یک نویسه صریح "%".
-
اگر --write-out چندین بار مشخص شود، آخرین مقدار تعیینشده استفاده میشود.
مثال:
curl -w '%{response_code}\n' https://example.comهمچنین --verbose و --head را ببینید.
- --xattr
- ذخیره
فراداده در
صفتهای
توسعهیافته
پرونده.
هنگام ذخیره خروجی در یک پرونده، به curl اعلام میکند فراداده پرونده را در صفتهای توسعهیافته پرونده ذخیره کند. در حال حاضر، "curl" در صفت "creator"، نشانی URL در صفت "xdg.origin.url"، و برای HTTP نوع محتوا در صفت "mime_type" ذخیره میشود، و در صورت تعیین شدن، نشانی URL ارجاعدهنده در "user.xdg.referrer.url". اگر سیستم پرونده از صفتهای توسعهیافته پشتیبانی نکند، یک هشدار صادر میشود.
از curl 8.22.0 این گزینه در Windows نیز پشتیبانی میشود، که در آن یک Alternate Data Stream با نام "Zone.Identifier" ایجاد میکند. این جریان شامل بخشی با قالب INI به نام "ZoneTransfer"، با مقادیر "HostUrl" و "ReferrerUrl" (در صورت تنظیم) است.
مشخص کردن چندباره --xattr هیچ تأثیر اضافهای ندارد. آن را دوباره با --no-xattr غیرفعال کنید.
مثال:
curl --xattr -o storage https://example.com
همچنین --remote-time، --write-out و --verbose را ببینید.
فایلها (FILES)
~/.curlrc
فایل پیکربندی پیشفرض، برای جزئیات --config را ببینید.
متغیرهای محیطی (ENVIRONMENT)
متغیرهای محیطی را میتوان با حروف کوچک یا حروف بزرگ مشخص کرد. نسخه حروف کوچک اولویت دارد. «http_proxy» یک استثنا است زیرا فقط با حروف کوچک در دسترس است. (توجه داشته باشید که برخی از سیستمها، مانند Windows، بین حروف کوچک و بزرگ در متغیرهای محیطی تفاوتی قائل نمیشوند.)
استفاده از یک متغیر محیطی برای تنظیم پراکسی همان تأثیر استفاده از گزینه --proxy را دارد.
- http_proxy [protocol://]<host>[:port]
- سرور پراکسی مورد استفاده برای HTTP را تعیین میکند.
- HTTPS_PROXY [protocol://]<host>[:port]
- سرور پراکسی مورد استفاده برای HTTPS را تعیین میکند.
- [url-protocol]_PROXY [protocol://]<host>[:port]
- سرور پراکسی مورد استفاده برای [url-protocol] را تعیین میکند، که در آن پروتکل، پروتکلی است که curl از آن پشتیبانی میکند و همانطور که در یک URL مشخص شده است: FTP، FTPS، POP3، IMAP، SMTP، LDAP و غیره.
- ALL_PROXY [protocol://]<host>[:port]
- سرور پراکسی مورد استفاده در صورتی که هیچ پراکسی ویژهای برای پروتکل تنظیم نشده باشد را تعیین میکند.
- NO_PROXY <comma-separated list of hosts/domains>
- فهرستی از
نامهای
میزبان که
نباید از
هیچ
پراکسیای
عبور کنند.
اگر تنها
روی یک
ستاره '*'
تنظیم شود،
با همه
میزبانها
مطابقت
مییابد. هر
نام در این
فهرست یا به
عنوان یک
نام دامنه
که شامل نام
میزبان
است، یا خود
نام میزبان
مطابقت
داده میشود.
این متغیر محیطی استفاده از پراکسی را حتی زمانی که با گزینه --proxy مشخص شده باشد غیرفعال میکند. یعنی
NO_PROXY=direct.example.com curl -x http://proxy.example.com https://direct.example.com
به طور مستقیم به URL مقصد دسترسی پیدا میکند، و
NO_PROXY=direct.example.com curl -x http://proxy.example.com https://somewhere.example.com
از طریق پراکسی به URL مقصد دسترسی پیدا میکند.
فهرست نامهای میزبان همچنین میتواند شامل نشانیهای عددی IP باشد، و نسخههای IPv6 باید در این حالت بدون براکتهای دربرگیرنده مشخص شوند.
نشانیهای IP را میتوان با نمادگذاری CIDR مشخص کرد: یک اسلش و عددِ الحاق شده تعداد «بیتهای شبکه» از نشانی را برای استفاده در مقایسه مشخص میکند (در نسخه 7.86.0 افزوده شد). برای نمونه «192.168.0.0/16» با تمام نشانیهایی که با «192.168» شروع میشوند مطابقت دارد.
- APPDATA <directory>
- در Windows، این متغیر هنگام تلاش برای یافتن دایرکتوری خانگی استفاده میشود، در صورتی که متغیرهای خانگی اصلی همگی تنظیم نشده باشند.
- COLUMNS <terminal width>
- در صورت تنظیم، تعداد نویسههای مشخص شده به عنوان عرض ترمینال هنگام نمایش نوار پیشرفت (progress-bar) جایگزین استفاده میشود. در صورت عدم تنظیم، curl تلاش میکند آن را از راههای دیگر بیابد.
- CURL_CA_BUNDLE <file>
- در صورت تنظیم، به عنوان مقدار --cacert استفاده میشود. این متغیر محیطی در صورتی که از Schannel به عنوان بکاند TLS استفاده شود نادیده گرفته میشود.
- CURL_HOME <directory>
- در صورت تنظیم، نخستین متغیری است که curl هنگام تلاش برای یافتن دایرکتوری خانگی خود بررسی میکند. در صورت عدم تنظیم، به بررسی XDG_CONFIG_HOME ادامه میدهد.
- CURL_SSL_BACKEND <TLS backend>
- اگر curl با
پشتیبانی
از «MultiSSL»
ساخته شده
باشد، به
این معنی که
پشتیبانی
داخلی از
بیش از یک
بکاند TLS
دارد، این
متغیر
محیطی
میتواند
روی نام
غیرحساس به
حروفِ
بکاند خاصی
که هنگام
فراخوانی curl
استفاده
میشود
تنظیم شود.
تنظیم نامی
که یک
جایگزین
داخلی
نباشد باعث
میشود curl با
پیشفرض
باقی بماند.
نامهای بکاند SSL (غیرحساس به حروف): gnutls، mbedtls، openssl، rustls، schannel، wolfssl
- HOME <directory>
- در صورت تنظیم، در زمان نیاز برای یافتن دایرکتوری خانگی استفاده میشود. مانند زمانی که به دنبال .curlrc پیشفرض میگردد. CURL_HOME و XDG_CONFIG_HOME اولویت دارند.
- NETRC <path>
- در صورت تنظیم، برای یافتن فایل «.netrc» استفاده میشود. این متغیر بر تمام سازوکارهای دیگرِ مکانیابی فایل netrc اولویت دارد و باید روی مسیر کامل فایل تنظیم شود. (در curl 8.16.0 افزوده شد)
- QLOGDIR <directory>
- اگر curl با پشتیبانی از HTTP/3 ساخته شده باشد، تنظیم این متغیر محیطی به یک دایرکتوری محلی باعث میشود curl فایلهای qlogs را در آن دایرکتوری، با استفاده از نامهایی برگرفته از شناسه اتصال مقصد (به صورت هگزادسیمال) تولید کند. توجه داشته باشید که این فایلها میتوانند بسیار حجیم شوند. با بکاندهای QUIC شامل ngtcp2 و quiche کار میکند.
- SHELL
- در VMS هنگام تلاش برای تشخیص استفاده از شل DCL یا Unix به کار میرود.
- SSL_CERT_DIR <directory>
- در صورت تنظیم، به عنوان مقدار --capath استفاده میشود. این متغیر محیطی در صورتی که از Schannel به عنوان بکاند TLS استفاده شود نادیده گرفته میشود.
- SSL_CERT_FILE <path>
- در صورت تنظیم، به عنوان مقدار --cacert استفاده میشود. اگر از Schannel به عنوان بکاند TLS استفاده شود، این متغیر محیطی نادیده گرفته میشود.
- SSLKEYLOGFILE <path>
- اگر این متغیر محیطی را روی یک نام فایل تنظیم کنید، curl هنگام فراخوانی، اسرار TLS اتصالات خود را در آن فایل ذخیره میکند تا بتوانید با استفاده از ابزارهای تحلیل شبکه مانند Wireshark ترافیک TLS را به صورت بیدرنگ تحلیل کنید. این قابلیت با بکاندهای TLS زیر کار میکند: OpenSSL، LibreSSL (حداکثر TLS 1.2)، BoringSSL، GnuTLS، wolfSSL و Rustls.
- USERPROFILE <directory>
- در Windows، هنگامی که سایر متغیرهای اصلی همگی تنظیم نشده باشند، از این متغیر برای یافتن دایرکتوری خانگی استفاده میشود. در صورت تنظیم، curl از مسیر "$USERPROFILE\Application Data" استفاده میکند.
- XDG_CONFIG_HOME <directory>
- اگر CURL_HOME تنظیم نشده باشد، این متغیر هنگام جستجو برای یک فایل پیشفرض .curlrc بررسی میشود.
پیشوندهای پروتکل پروکسی (PROXY PROTOCOL PREFIXES)
رشته پروکسی میتواند با پیشوند "protocol://" مشخص شود تا پروتکلهای جایگزین پروکسی تعیین شوند.
اگر هیچ پروتکلی در رشته پروکسی مشخص نشده باشد یا رشته با موارد پشتیبانیشده مطابقت نداشته باشد، با پروکسی مانند یک پروکسی HTTP رفتار میشود.
پیشوندهای پروتکل پروکسی پشتیبانیشده به شرح زیر هستند:
- http://
- باعث میشود از آن به عنوان یک پروکسی HTTP استفاده شود. در صورت عدم استفاده از پیشوند طرحواره (scheme)، این حالت پیشفرض است.
- https://
- باعث میشود به عنوان یک پروکسی HTTPS در نظر گرفته شود.
- socks4://
- آن را معادل --socks4 میکند.
- socks4a://
- آن را معادل --socks4a میکند.
- socks5://
- آن را معادل --socks5 میکند.
- socks5h://
- آن را معادل --socks5-hostname میکند.
کدهای خروج (EXIT CODES)
مجموعهای از کدهای خطای مختلف و پیامهای خطای متناظر آنها وجود دارند که ممکن است تحت شرایط بروز خطا ظاهر شوند. در زمان نگارش این مستند، کدهای خروج عبارتند از:
- 0
- موفقیت. عملیات مطابق با دستورالعملها با موفقیت انجام شد.
- 1
- پروتکل پشتیبانینشده. این ساخت از curl از این پروتکل پشتیبانی نمیکند.
- 2
- خطا در راهاندازی اولیه.
- 3
- نشانی URL بدساخت. ساختار نحو صحیح نبود.
- 4
- ویژگی یا گزینهای که برای انجام درخواست مورد نظر لازم بود فعال نشده یا صراحتاً در زمان ساخت (build-time) غیرفعال شده است. برای اینکه curl قادر به انجام این کار باشد، احتمالاً به ساخت دیگری از libcurl نیاز دارید.
- 5
- امکان تحلیل نشانی پروکسی وجود ندارد. میزبان پروکسی دادهشده قابل تحلیل نبود.
- 6
- امکان تحلیل نشانی میزبان وجود ندارد. میزبان راه دور دادهشده قابل تحلیل نبود.
- 7
- خطا در اتصال به میزبان.
- 8
- پاسخ عجیب سرور. سرور دادهای ارسال کرد که curl قادر به تجزیه آن نبود.
- 9
- دسترسی FTP رد شد. سرور از ورود ممانعت کرد یا دسترسی به منبع یا دایرکتوری خاصی را که میخواستید به آن برسید رد کرد. بیشتر اوقات به این دلیل است که سعی کردهاید به دایرکتوریای بروید که روی سرور وجود ندارد.
- 10
- پذیرش FTP ناموفق بود. در حین انتظار برای برقراری اتصال متقابل از سوی سرور در زمان استفاده از یک نشست فعال FTP، یک کد خطا از طریق اتصال کنترلی یا مشابه آن ارسال شد.
- 11
- پاسخ عجیب FTP به درخواست PASS. ابزار curl نتوانست پاسخ ارسالی به درخواست PASS را تجزیه کند.
- 12
- در طول یک نشست فعال FTP، در حین انتظار برای برقراری اتصال مجدد سرور به curl، مهلت زمانی منقضی شد.
- 13
- پاسخ عجیب FTP به درخواست PASV. ابزار curl نتوانست پاسخ ارسالی به درخواست PASV را تجزیه کند.
- 14
- قالب نامتعارف 227 در FTP. ابزار curl نتوانست خط 227-line ارسالشده توسط سرور را تجزیه کند.
- 15
- عدم امکان استفاده FTP از میزبان. آدرس IP میزبانی که در 227-line دریافت شد قابل تحلیل نبود.
- 16
- خطای HTTP/2. مشکلی در لایه قاببندی (framing) پروتکل HTTP2 شناسایی شد. این یک خطای عمومی است و میتواند ناشی از یکی از چندین مشکل احتمالی باشد؛ برای جزئیات به پیام خطا مراجعه کنید.
- 17
- عدم امکان تنظیم حالت باینری در FTP. امکان تغییر روش انتقال به باینری وجود نداشت.
- 18
- فایل ناقص. تنها بخشی از فایل منتقل شد.
- 19
- عدم امکان بارگیری/دسترسی FTP به فایل دادهشده. دستور RETR (یا مشابه آن) ناموفق بود.
- 21
- خطای FTP quote. دستور quote خطایی از سرور برگرداند.
- 22
- صفحه HTTP دریافت نشد. URL درخواستی پیدا نشد یا خطای دیگری با کد خطای HTTP معادل 400 یا بالاتر بازگردانده شد. این کد بازگشتی تنها در صورتی ظاهر میشود که از --fail استفاده شده باشد.
- 23
- خطای نوشتن. curl نتوانست دادهها را روی سامانه پرونده محلی یا موارد مشابه بنویسد.
- 25
- شروع بارگذاری ناموفق بود. برای FTP، سرور معمولاً دستور STOR را رد کرده است.
- 26
- خطای خواندن. مشکلات مختلف در خواندن.
- 27
- کمبود حافظه. درخواست تخصیص حافظه با شکست مواجه شد.
- 28
- پایان مهلت زمانی عملیات. با توجه به شرایط، مهلت زمانی مشخصشده به پایان رسید.
- 30
- دستور FTP PORT ناموفق بود. دستور PORT با شکست مواجه شد. همه سرورهای FTP از دستور PORT پشتیبانی نمیکنند، بهجای آن انتقال را با استفاده از PASV امتحان کنید.
- 31
- پروتکل FTP نتوانست از REST استفاده کند. دستور REST با شکست مواجه شد. این دستور برای ادامه انتقالهای ناقص FTP استفاده میشود.
- 33
- خطای محدوده HTTP. «دستور» محدوده (range) کار نکرد.
- 34
- خطای HTTP post. خطای داخلی در ایجاد درخواست post.
- 35
- خطای اتصال SSL. دستتکانی SSL با شکست مواجه شد.
- 36
- ادامه ناموفق بارگیری. ادامه بارگیری متوقفشده قبلی امکانپذیر نبود.
- 37
- پروتکل FILE نتوانست پرونده را بخواند. باز کردن پرونده ناموفق بود. مجوزها؟
- 38
- عدم امکان اتصال به LDAP. عملیات LDAP bind با شکست مواجه شد.
- 39
- جستجوی LDAP ناموفق بود.
- 41
- تابع پیدا نشد. یک تابع مورد نیاز LDAP یافت نشد.
- 42
- لغو شده توسط بازخوانی (callback). یک برنامه به curl اعلام کرد که عملیات را لغو کند.
- 43
- خطای داخلی. یک تابع با آرگومان نامعتبر فراخوانی شده است.
- 45
- خطای رابط شبکه (Interface). رابط خروجی مشخصشده قابل استفاده نبود.
- 47
- تغییرمسیرهای بیش از حد. هنگام دنبال کردن تغییرمسیرها، curl به حداکثر تعداد مجاز رسید.
- 48
- گزینه ناشناختهای برای libcurl مشخص شده است. این نشان میدهد که گزینه عجیبی به curl دادهاید که به libcurl منتقل شده و رد شده است. راهنما را مطالعه کنید.
- 49
- گزینه نامعتبر telnet.
- 52
- سرور هیچ پاسخی ارسال نکرد، که در اینجا یک خطا در نظر گرفته میشود.
- 53
- موتور رمزنگاری SSL یافت نشد.
- 54
- تنظیم موتور رمزنگاری SSL به عنوان پیشفرض امکانپذیر نیست.
- 55
- ارسال دادههای شبکه با شکست مواجه شد.
- 56
- شکست در دریافت دادههای شبکه.
- 58
- مشکل در گواهی محلی.
- 59
- الگوریتم رمزنگاری (cipher) مشخصشده برای SSL قابل استفاده نبود.
- 60
- گواهی همتا (Peer) با گواهیهای شناختهشده CA قابل احراز هویت نیست.
- 61
- کدگذاری انتقال (transfer encoding) ناشناخته است.
- 63
- اندازه پرونده از حداکثر مجاز فراتر رفت.
- 64
- سطح درخواستی FTP SSL با شکست مواجه شد.
- 65
- ارسال دادهها نیازمند بازپیچی (rewind) است که با شکست مواجه شد.
- 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
- بررسی صادرکننده (Issuer) ناموفق بود.
- 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 است.
- 97
- خطای دستتکانی پروکسی.
- 98
- برای تکمیل دستتکانی TLS به یک گواهی سمت کلاینت نیاز است.
- 99
- فراخوانی poll یا select خطای مهلکی برگرداند.
- 100
- یک مقدار یا فیلد داده بزرگتر از حد مجاز شد.
- XX
- ممکن است در نسخههای آینده کدهای خطای بیشتری در اینجا ظاهر شوند. کدهای موجود طوری طراحی شدهاند که هرگز تغییر نکنند.
باگها (BUGS)
اگر با curl به هر مشکلی برخوردید، یک گزارش مشکل (issue) در سامانه پیگیری باگ پروژه در GitHub ثبت کنید: https://github.com/curl/curl/issues
نویسندگان (AUTHORS)
Daniel Stenberg نویسنده اصلی است، اما فهرست کامل مشارکتکنندگان در پرونده جداگانه THANKS یافت میشود.
وبگاه (WWW)
همچنین ببینید (SEE ALSO)
| 2026-09-02 | curl 8.22.0 |