Curl’a başka bir şey yapmasını söylemediğinizde, curl bir GET isteği gönderir. Bu da bu soruya verilebilecek en kısa ve eksiksiz cevabın tek kelimeden ibaret olmasını sağlar:
curl https://example.com
Bu bir GET isteğidir. Doğru ve dil kurallarına uygundur; eğer ihtiyacınız olan tek şey buysa, okumaya devam etmenize gerek yok.
Biz [Geonode
](https://geonode.com/) olarak proxy satıyoruz; bu nedenle en baştan şunu açıkça belirtmeliyiz: bu makaledeki hemen hemen hiçbir şey için proxy gerekmez. curl, kendi başına internetle gayet iyi iletişim kurar ve GET isteklerinin ezici çoğunluğu — bir API'ye erişmek, bir dosyayı indirmek, bir hizmetin çalışıp çalışmadığını kontrol etmek, bir başlığı hata ayıklamak — hiçbir türde proxy gerektirmez. Aşağıda, coğrafi testler ve büyük hacimli veri toplama için gerçekten ihtiyaç duyulduğu için curl'ü bir proxy üzerinden yönlendirmeyle ilgili bir bölüm ve proxy kullanmanın yanlış bir hareket olduğu durumlarla ilgili bir bölüm daha bulunmaktadır. İhtiyacınız olmayan bir şey satın almanız yerine, her ikisini de atlamanızı tercih ederiz.
Bu kılavuzun asıl amacı, tek satırlık komutların bir üst seviyesindeki işlemleri ele almaktır: sorgu dizelerini kabuk tarafından yutulmadan bir araya getirmek, tahminde bulunmak yerine gerçekten neyin döndüğünü görmek ve gerçekten şaşırtıcı olan iki veya üç tuzağı önlemek. Aşağıda açıklanan her davranış, herhangi birinin hafızasına dayanmak yerine, her ikisi de projenin kendisi tarafından güncellenen curl’un kendi belgelerinden ve curl kitabından alınmıştır.
Bu tuzaklardan en yararlı olanı hemen bir sonraki bölümde yer almaktadır ve binlerce öğretici kılavuzun kullanmanızı tavsiye ettiği bir bayrakla ilgilidir.
En Basit GET İsteği
Buradan başlayın ve sadece ihtiyacınız olanları ekleyin.
curl https://api.example.com/users
curl, bir GET isteği gönderir ve yanıt gövdesini standart çıktıya yazar. Yöntem bayrağı yok, başlık yok, başka hiçbir şeye gerek yok.
Bir Dosyaya Kaydetme
İki yol var ve aradaki fark önemlidir.
# Write to a filename you choose
curl -o users.json https://api.example.com/users
# Write using the filename from the URL
curl -O https://example.com/files/report.pdf
Küçük harfli -o
bir dosya adı alır. Büyük harfli -O
ise URL’nin son yol segmentini kullanır; bu, indirmeler için kullanışlıdır ancak dosya adı içermeyen bir yolla biten API uç noktaları için işe yaramaz.
Sessiz Mod
Varsayılan olarak curl, çıktı bir terminal olmadığında standart hata akışına bir ilerleme göstergesi yazar; bu da günlükleri ve komut dosyalarını karmaşık hale getirir.
curl -s https://api.example.com/users
-s
, ilerleme göstergesini sessize alır — ve ne yazık ki hata mesajlarını da. Komut dosyalarında neredeyse her zaman şunu istersiniz:
curl -sS https://api.example.com/users
-sS
, "sessiz, ancak hataları yine de göster" anlamına gelir. Bu kombinasyon, otomatikleştirilmiş her şeyde varsayılan ayarınız olmalıdır. Sessizce hata veren sessiz bir curl, uygunsuz bir zamanda teşhis edilmeyi bekleyen bir hatadır.
HTTP Hatalarında Düzgün Şekilde Hata Verin
Bu durum neredeyse herkesi yakalar.
curl -sS https://api.example.com/missing
# prints the error page body, exits with status 0
curl, 404 kodunu başarılı bir aktarım olarak değerlendirir; çünkü aktarım başarılı olmuştur — sunucu yanıt vermiştir. Çıkış kodu, curl'ün çalışıp çalışmadığını gösterir, sunucunun memnun olup olmadığını değil.
curl -sSf https://api.example.com/missing
# prints nothing, exits non-zero
-f
komutu, 400 ve üzeri HTTP hatalarında curl'ün sessizce hata vermesini ve sıfırdan farklı bir çıkış kodu döndürmesini sağlar. Başarısız bir isteğin iş akışını durdurması gereken herhangi bir komut dosyasında, **-sSf
istediğiniz kombinasyondur** ve bunun eksikliği, bozuk bir cron işinin çalışıyor gibi görünmesinin en yaygın nedenlerinden biridir.
-X GET Yazmayı Bırakın
İnternetteki curl örneklerinin büyük bir kısmında -X GET ifadesi yer almaktadır. Bu gereksizdir ve belirli, yaygın bir durumda açıkça zararlıdır.
Neden Gereksizdir?
curl kitabında bu durum açıkça belirtilmiştir: "curl'dan HTTP aktarımları gerçekleştirmesini istediğinizde, curl seçeneğe göre doğru yöntemi seçer; bu nedenle -X komutuyla bunu açıkça belirtmeniz nadiren gerekebilir."
curl zaten bunu bilir. Basit bir komut GET'tir. -d eklediğinizde POST olur. -I eklediğinizde HEAD olur. -T ekleyin, PUT olur. Yöntem, talep ettiğiniz şeyden kaynaklanır ve bunu tekrar belirtmenin bir anlamı yoktur.
Neden Sorunlara Neden Olabilir?
İşte hatırlamaya değer kısım. Aynı belgeden alıntı: "curl, -L ile talep edildiği gibi yönlendirmeleri takip ettiğinde, -X ile ayarlanan istek yöntemi, sonraki yönlendirmelerde bile gönderilir."
İşte tuzak da budur. Normalde curl, yönlendirme zincirini takip ederken yöntemi uygun şekilde ayarlar. -X ile yöntemi zorlarsanız, bu ayarlama işlemi durur — zorladığınız yöntem, yönlendirmenin gerçekte ne istediğine bakılmaksızın zincirdeki her URL’ye gönderilir.
Bir GET isteğinde -X GET kullanılması genellikle zararsızdır, çünkü cevap zaten GET olacaktı. Ancak birisi bu kalıbı, veri gönderen ve yönlendirmeleri takip eden bir komuta kopyaladığı anda durum zararsız olmaktan çıkar; bu noktada istek, hata ayıklaması gerçekten zor olacak şekilde sessizce hatalı hale gelir — komut normal görünür, ancak sunucu başka bir şey görür.
Bununla ilgili belgelenmiş bir örnek, -X HEAD adresidir; bu durumda sistem kilitlenir: HEAD yanıtları gövde içermez, ancak curl’a niyet yerine yöntem belirtildiği için, asla gelmeyecek verileri bekler.
Kural
-X'i yalnızca curl'ün bir seçeneği bulunmayan yöntemlere ihtiyacınız olduğunda kullanın — DELETE, PATCH veya özel bir yöntem gibi. GET için bunu atlayın. Daha kısa komut aynı zamanda daha doğru olandır; bu da nadir görülen ve hoş bir kombinasyondur.
Sorgu Dizelerini Doğru Şekilde Oluşturma
GET istekleri parametrelerini URL’de taşır ve işte bu noktada kabuk (shell) sorunlara yol açmaya başlar.
URL’lerinizi Tırnak İşareti İçine Alın
# Broken: & backgrounds the command, ? may glob
curl https://api.example.com/search?q=test&page=2
# Correct
curl "https://api.example.com/search?q=test&page=2"
Kabukta, & komutları ayırır ve ? joker karakterdir. Bunları içeren ve tırnak işareti içine alınmamış bir URL, bölünecek, bozulacak veya sessizce kesilecektir. URL'leri her zaman tırnak içine alın. Bu hiçbir maliyeti yoktur ve kafa karıştırıcı hataların bir türünü önler.
Sorgu Dizesini Oluşturma İşini curl'e Bırakın
İki parametreden fazlası olduğunda veya herhangi bir parametrede boşluk bulunduğunda, URL'yi elle oluşturmak zahmetli ve hataya açık bir işlem haline gelir. curl'ün daha iyi bir yöntemi vardır.
-G bayrağı, belgelere göre, "--data, --data-binary veya --data-urlencode ile belirtilen tüm verilerin POST isteği yerine bir HTTP GET isteğinde kullanılmasını sağlar".
curl -G https://api.example.com/search \
--data-urlencode "q=proxy servers" \
--data-urlencode "country=United Kingdom" \
--data-urlencode "page=2"
curl bunu ?q=proxy%20servers&country=United%20Kingdom&page=2 şeklinde birleştirir ve bir GET isteği gönderir. Boşluklar, ve işaretleri, aksanlı karakterler — hepsi siz düşünmenize gerek kalmadan doğru şekilde kodlanır.
Bu, API'lerle düzenli olarak çalışan herkes için bu makaledeki en yararlı bilgidir. Manuel yüzde kodlaması bir bilgisayarın yapacağı bir iştir ve elinizde zaten bir tane var.
--data-urlencode Biçimleri
Belgelerde birkaç sözdizimi listelenmiştir ve bunlar farklı şekilde çalışır:
| Biçim | Ne yapar |
|---|
content | = dahil olmak üzere tüm dizeyi kodlar |
=content | İçeriği kodlar, parametre adı gönderilmez |
name=content | Yalnızca içeriği kodlar, name'yi olduğu gibi bırakır |
@filename | Dosyanın içeriğini kodlar |
name@filename | Dosyanın içeriğini name altında kodlar |
Unutmamanız gereken, name=content şeklindedir; bu, neredeyse her zaman istediğiniz şeydir: parametre adı değiştirilmeden geçer ve değer kodlanır. Bunu tersine yaparsanız — yani adı da kodlarsanız — sunucu hata mesajının açıklayamayacağı şekillerde başarısız olan istekler ortaya çıkar.
Gerçekte Neler Olduğunu Görmek
Yalnızca yanıt gövdesi, genellikle bilmeniz gerekenleri size vermez.
Gövdeyle Birlikte Başlıklar
curl -i https://api.example.com/users
-i
, yanıt başlıklarını gövdeden önce içerir. Durum satırı, içerik türü, hız sınırı başlıkları veya beklemediğiniz bir Set-Cookie
'a ihtiyacınız olduğunda kullanışlıdır.
curl -I https://example.com
Büyük harfli -I
bir HEAD isteği gönderir ve yalnızca başlıkları gösterir. Hiçbir şey indirmeden bir kaynağın var olup olmadığını, boyutunun ne olduğunu ve bir URL'nin nereye yönlendirdiğini kontrol etmek için kullanışlıdır.
Tam Ayrıntılı Çıktı
curl -v https://api.example.com/users
-v
, curl tarafından gönderilen isteği ve yanıtı gösterir; burada >
giden satırları, <
ise gelen satırları işaretler. Bu, bir istek beklediğinizden farklı davrandığında başvurmanız gereken ilk şeydir; çünkü göndermek istediğiniz şeyden ziyade gerçekte neyin gönderildiğini gösterir — ve bu ikisi, kimsenin kabul etmek istemese de, sıklıkla birbirinden farklıdır.
Daha da ayrıntılı bilgi için, --trace-ascii -
komutu gövdeler dahil olmak üzere tüm iletişim içeriğini görüntüler.
Yalnızca Durum Kodu
Komut dosyaları ve durum kontrolleri için:
curl -s -o /dev/null -w "%{http_code}\n" https://example.com
Bu komut, gövdeyi atar, ilerleme göstergesini devre dışı bırakır ve yalnızca durum kodunu görüntüler. -w
(yazdırma) komutu çeşitli değişkenleri destekler ve bunlardan birkaçını birleştirerek kompakt bir tanılama satırı elde edebilirsiniz:
curl -s -o /dev/null \
-w "status=%{http_code} time=%{time_total}s size=%{size_download}\n" \
https://example.com
Bu tek komut, kullanışlı bir çalışma süresi ve gecikme kontrolü sağlar ve herhangi bir ek araca gerek kalmadan izleme komut dosyalarına entegre edilebilir.
Zaman Dağılımı
Bir işlem yavaşladığında ve hangi kısmın yavaşladığını bilmeniz gerektiğinde:
curl -s -o /dev/null \
-w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://example.com
Bu sayılar arasındaki farklar, sürenin nereye gittiğini gösterir: yavaş DNS, yavaş TCP el sıkışma süreci, yavaş TLS müzakeresi veya yanıt vermeye başlaması uzun süren bir sunucu. Bu, toplam rakamdan çok daha fazla bilgi sağlar ve bir performans sorununun sizden mi yoksa karşı taraftan mı kaynaklandığını belirlemenin en hızlı yoludur.
Başlıklar, Çerezler ve Kimlik Doğrulama
Özel Başlıklar
curl -H "Accept: application/json" \
-H "X-API-Key: your-key-here" \
https://api.example.com/users
Her başlık için -H
adresindeki adımları tekrarlayın. Bilmeniz gereken iki nokta:
curl’un normalde göndereceği bir başlığı kaldırmak için, başlığa değer vermeyin: -H "User-Agent:"
. Gerçekten boş bir değere sahip bir başlık göndermek için noktalı virgül kullanın: -H "X-Empty;"
.
Ve belgelerden önemli bir uyarı: -H
ile ayarlanan başlıklar "tüm HTTP isteklerinde ayarlanır — yönlendirmeler takip edildikten sonra bile", bu nedenle "hassas başlıklar dikkatli kullanılmalıdır". Bir istek, beklemediğiniz bir ana bilgisayara yönlendirilirse, API anahtarınız da onunla birlikte gider.
Kimlik Doğrulama
# Basic auth
curl -u username:password https://api.example.com/private
# Bearer token
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/private
# Prompt for the password instead of putting it in shell history
curl -u username https://api.example.com/private
Bu son biçim, fazladan bir tuş vuruşuna değer. Komut satırındaki şifreler, kabuk geçmişinize kaydedilir ve makinedeki diğer herkes tarafından işlem listesinde görülebilir. Şifreyi atladığınızda, curl sizden şifre girmenizi ister.
Çerezler
# Send cookies inline
curl -b "session=abc123; lang=en" https://example.com
# Save cookies the server sets
curl -c cookies.txt https://example.com/login
# Send them back on the next request
curl -b cookies.txt https://example.com/dashboard
-c
bir çerez dosyası yazar, -b
ise bir çerez dosyasını okur. Bir dizi istek boyunca ikisini birlikte kullanmak, oturumu sürdürmenin yoludur; "bu neden tarayıcımda çalışıyor da curl'da çalışmıyor" şeklindeki sorunların çoğu aslında bununla ilgilidir.
Yönlendirmeler, Sıkıştırma ve Zaman Aşımları
Neredeyse her gerçek hayattaki komutta yer alan üç bayrak.
Yönlendirmeleri Takip Etme
curl -L https://example.com/old-page
curl, varsayılan olarak yönlendirmeleri takip etmez. 301 kodunu bildirir ve durur. -L komutu, yönlendirmeleri takip etmesini sağlar; --max-redirs ise ne kadar uzağa kadar takip edileceğini sınırlar.
Belgelerde yer alan, bilinmesi gereken bir güvenlik detayı: Authorization ve Cookie başlıkları, "--location-trusted kullanılmadıkça, diğer kaynaklara yapılan yönlendirmeleri takip ederken HTTP isteklerinde açıkça aktarılmaz". Bu mantıklı bir varsayılan davranıştır — kimlik bilgileriniz sizi farklı bir ana bilgisayara kadar takip etmez. Yukarıda açıklanan ve takip eden -H başlıklarıyla olan asimetriye dikkat edin. API anahtarını -u yerine -H ile ayarlarsanız, curl bunun bir kimlik bilgisi olduğunu bilmez ve sorunsuz bir şekilde iletir.
Sıkıştırma
curl --compressed https://example.com
Bu, sıkıştırılmış bir yanıt talep eder ve belgelere göre "içeriği otomatik olarak açar". Metin ağırlıklı yanıtlarda aktarım boyutunu önemli ölçüde azaltır; bu, bant genişliği sınırlı olduğunda büyük önem taşır.
Belgelerde dikkate alınması gereken bir uyarı yer almaktadır: "Veriler açılırken, çok küçük aktarımlar bile genişleyebilir ve çok büyük miktarda bayt oluşturabilir." Küçük bir sıkıştırılmış yanıt, açıldığında devasa bir boyuta ulaşabilir. Otomatik bir sistemde curl'ü güvenilir olmayan URL'lere yönlendiriyorsanız, küçük bir indirmenin küçük kalacağını varsaymak yerine, çıktıyı --max-filesize ile sınırlayın.
Zaman Aşımları
curl --connect-timeout 5 --max-time 30 https://example.com
Bu ikisi farklıdır ve her ikisi de kullanışlıdır. --connect-timeout "yalnızca bağlantı aşamasını sınırlar" — curl bu süre içinde bağlantı kurarsa, geri kalanının ne kadar sürerse sürsün devam eder. --max-time tüm işlemi sınırlar ve "ondalık değerleri kabul eder".
Bunlar olmadan, bir komut dosyasında yer alan curl, yanıt vermeyen bir sunucuya karşı fiilen sonsuza kadar takılı kalabilir. Otomasyondaki her curl komutunda bir --max-time bulunmalıdır. Bu, mevcut en ucuz güvenilirlik iyileştirmesidir ve sadece on bir karakterlik bir kod gerektirir.
Yeniden Denemeler
curl --retry 3 --retry-delay 2 --retry-max-time 60 https://api.example.com/data
Geçici hatalarda, denemeler arasında bir gecikme süresi bırakılarak yeniden denemeler yapılır. -sSf ile birleştirildiğinde, yeniden deneme hakkı tükendiğinde hatalar gerçekten ortaya çıkar.
Proxy Üzerinden GET İsteği Gönderme
Bu, ürünümüzün uzmanlık alanı olduğu için bu konudaki coşkumuzu anlayışla karşılayın — ancak işleyişini bilmekte fayda var ve buradaki bir ayrıntı gerçek bir tuzak niteliğinde.
Temel Sözdizimi
curl -x http://proxy.example.com:8080 https://api.example.com/data
# With authentication
curl -x http://username:password@proxy.example.com:8080 https://api.example.com/data
# Or separately
curl -x http://proxy.example.com:8080 --proxy-user username:password https://api.example.com/data
Bilinmesi gereken yararlı bir varsayılan ayar: curl kitabına göre, “varsayılan proxy türü HTTP’dir; dolayısıyla, şema kısmı olmadan bir proxy ana bilgisayar adı (veya IP adresi) belirtirseniz... curl, bunun bir HTTP proxy’si olduğunu varsayar.” SOCKS'u kastetmiş ve şemayı atlamışsanız, curl sessizce başka bir şey yapmıştır.
SOCKS ve Kimsenin Bahsetmediği DNS Sızıntısı
curl birkaç SOCKS biçimini kabul eder:
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com
Bunlar birbirinin yerine kullanılabilir gibi görünür. Ancak öyle değildir ve bu, bu bölümden akılda tutulması gereken bir ayrıntıdır.
**socks5
** biçiminde, belgelere göre, "curl adı çözümler" — proxy'ye bağlanmadan önce, yerel olarak, makinenizde. **socks5h
** biçiminde ise, curl "ana bilgisayar adını proxy'ye gönderir, böylece curl tarafından yerel olarak herhangi bir ad çözümlemesi yapılmaz".
Sonuç: **socks5
, ziyaret ettiğiniz her ana bilgisayar adını yerel DNS çözümleyicinize** sızdırır; bu genellikle İSS'niz veya ağ operatörünüzdür. Trafik proxy üzerinden geçer; ancak nereye gittiğini herkese bildiren arama işlemi proxy üzerinden geçmez. Coğrafi veya gizlilik nedenleriyle bir proxy seçtiyseniz, socks5
bu seçiminizi kısmen boşa çıkarır. Ayrıca, yalnızca proxy'nin ağından doğru şekilde çözümlenen herhangi bir ana bilgisayar adında da sorun yaratır.
Aksi için özel bir nedeniniz yoksa, socks5h
kullanın. h
ana bilgisayar adı içindir, tek karakterden oluşur ve trafiğinizi yönlendirmekle, bunu duyurarak yönlendirmek arasındaki farktır.
Proxy'nin Gerçekten Kullanılıp Kullanılmadığını Doğrulama
curl -x http://proxy.example.com:8080 https://api.ipify.org
Geri dönen adres sizinki değil de proxy'ninkiyse, proxy çalışıyor demektir. -v
komutunu ekleyerek curl'ün gerçekten kurduğu bağlantıyı görebilirsiniz — bu sayede, curl'ün sessizce görmezden geldiği proxy URL'sindeki yazım hatalarını yakalayabilirsiniz.
Ortam Değişkenleri
export https_proxy="http://proxy.example.com:8080"
curl https://example.com # uses the proxy without -x
Kullanışlıdır, ancak başkaları tarafından ayarlandığında sık sık kafa karışıklığına neden olur. Bir proxy kullanılıyor gibi görünüyorsa ve -x
dosyası yoksa, başka herhangi bir şeyi kontrol etmeden önce ortam değişkenlerini kontrol edin.
Bunların Hiçbirine İhtiyacınız Olmadığında
Kendi çıkarlarımıza aykırı olarak: bir proxy’ye — ya da genel olarak curl’a — başvurmanın yanlış bir hareket olduğu birkaç durum.
Sıradan API çağrıları. Kimlik bilgilerine sahip olduğunuz bir API’ye, erişim izni olan bir sunucudan erişiyorsanız, buna hiçbir şey katmazsınız. Proxy, gecikme, arıza noktası ve hiçbir fayda sağlamayan bir masraf yaratır. Curl kullanımının büyük çoğunluğu bu kategoriye girer.
Herhangi bir hedefe yapılan az sayıda istek. Hız sınırlaması ve bot algılama, hacim ve kalıplara göre tepki verir. Bir öğleden sonraya yayılmış on istek, bir insan tarafından yapılmış gibi görünür. Küçük bir işe proxy eklemek, aslında olmayan bir sorunu çözmeye çalışmak demektir.
Dosya indirme. Halka açık bir URL'den curl -O komutunu kullanmak için başka hiçbir şeye gerek yoktur. Proxy'ler işlemi yavaşlatır ve maliyeti artırır.
Kendi altyapınızı test etme. Her iki ucu da siz kontrol ediyorsunuz. Doğrudan yönlendirin ve proxy geçişi dahil sayılar yerine gerçek sayıları görün.
Tarayıcının gerçekten gerekli olduğu her durum. Hedef, içeriğini JavaScript ile görüntülüyorsa, curl size boş bir sayfa getirir ve bunu hiçbir proxy düzeltemez. Başsız bir tarayıcıya ihtiyacınız vardır ve sayfa boş kalırken proxy'leri değiştirmek, öğleden sonranızı boşa harcamaktan başka bir şey değildir.
Engelleme, adresinizle ilgili değilse. Eksik başlıklar, olmayan çerezler, geçerliliğini yitirmiş bir token, yanlış içerik türü. Sorunun adresinizde olduğunu varsaymadan önce -v ile teşhis yapın — hatalı biçimlendirilmiş bir isteği düzeltmek için proxy satın almak, hatayı sürdürmenin pahalı bir yoludur.
Curl ile kullanılan proxy'ler üç durumda gerçekten işe yarar: bir sitenin veya reklamın belirli bir ülkeden nasıl görüntülendiğini kontrol etmek, adres başına hız sınırlamalarının bağlayıcı bir kısıtlama olduğu durumlarda büyük hacimli veri toplamak ve meşru nedenlerle coğrafi olarak kısıtlanmış hizmetlere erişmek. Bunların dışında, basit komut daha iyi bir seçenektir.
Sık Sorulan Sorular
curl ile GET isteği nasıl gönderilir?
curl’a bir URL vermeniz yeterlidir: curl https://example.com. GET, varsayılan yöntemdir; bu nedenle herhangi bir bayrak belirtilmesine gerek yoktur. URL’de sorgu dizesi varsa tırnak içine alın; çünkü & ve ?, komut satırınızda farklı anlamlara gelir.
curl ile -X GET kullanmam gerekir mi?
Hayır. curl, kullandığınız seçeneklerden yöntemi seçer ve belgelerde bunu gereksiz yere belirtmemeniz tavsiye edilir. Ayrıca bunun ciddi bir dezavantajı vardır: -L ile yönlendirmeleri takip ederken, -X ile zorlanan yöntem, her yönlendirme için ayrı ayrı ayarlanmak yerine zincirdeki her URL'ye gönderilir.
curl'da sorgu parametrelerini nasıl eklerim?
Parametreleri tırnak içine alınmış bir URL'ye ekleyebilir veya curl'un bunları oluşturmasına izin verebilirsiniz: curl -G https://api.example.com/search --data-urlencode "q=some value". İkinci yaklaşım, yüzde kodlamasını sizin için halleder ve birkaç parametreden fazlası olduğunda hataya çok daha az yol açar.
curl'da yanıt başlıklarını nasıl görebilirim?
-i başlıkları ve gövdeyi gösterir, -I bir HEAD isteği gönderir ve yalnızca başlıkları gösterir, -v ise curl'un gerçekten gönderdiği istek dahil olmak üzere tüm veri alışverişini gösterir. Hata ayıklama için önce -v komutunu kullanın.
curl neden hiçbir şey döndürmüyor?
Genellikle takip edilmeyen bir yönlendirme nedeniyle — -L seçeneğini belirtmediğiniz sürece curl yönlendirmeleri takip etmez. Ayrıca, gövde gerçekten boş olabilir ya da -o ile bir dosyaya gönderilmiş çıktı olabilir. Durum kodunu görmek ve hangisi olduğunu öğrenmek için komutu -i ile çalıştırın.
HTTP hatalarında curl'ün başarısız olmasını nasıl sağlarım?
-f seçeneğini ekleyin. Varsayılan olarak curl, 404 veya 500 hatalarını başarılı bir aktarım olarak değerlendirir ve aktarım başarılı olduğu için sıfır koduyla sonlanır. curl -sSf — sessiz, hataları göster, HTTP hatalarında başarısız ol — komut dosyaları için mantıklı bir varsayılan ayardır.
curl ile proxy'yi nasıl kullanırım?
Kimlik bilgilerini user:pass@host şeklinde curl -x http://proxy.example.com:8080 https://example.com, komutuyla veya --proxy-user adresi üzerinden girin. Şemayı belirtmezseniz, curl varsayılan olarak HTTP'yi kullanır. SOCKS için socks5:// yerine socks5h:// kullanın.
Curl'da socks5 ile socks5h arasındaki fark nedir?
Ana bilgisayar adını kim çözümler? socks5 kullanıldığında, curl bunu yerel olarak çözümler; bu da, trafik proxy üzerinden geçse bile DNS sağlayıcınızın ziyaret ettiğiniz her ana bilgisayarı görebileceği anlamına gelir. socks5h kullanıldığında ise ana bilgisayar adı proxy'ye gönderilir ve orada çözümlenir. socks5h kullanmayı tercih edin.
Sonuç
curl’da doğru GET isteği, curl ifadesinin ardından bir URL’nin gelmesidir. Bunun ötesindeki her şey ayrıntıdır ve içselleştirmeye değer ayrıntılar çok azdır.
-X GET’i kullanmayın. Bu gereksizdir, belgelerde kullanılması önerilmez ve yönlendirme davranışını, bu kalıp veri gönderen bir komuta kopyalandığında gerçek bir hata haline gelecek şekilde değiştirir.
Sorgu dizelerini curl'un oluşturmasına izin verin. -G ile --data-urlencode, kodlamayı her seferinde doğru şekilde işler ve yararsız sunucu hatalarına neden olan bir hata türünü tamamen ortadan kaldırır.
Otomatikleştirilmiş işlemlerde -sSf ve --max-time kullanın. Sessiz çalışır ancak hatalar konusunda sessiz kalmaz, HTTP hatalarında sıfırdan farklı çıkış kodu verir ve bir isteğin ne kadar süreyle askıda kalabileceğine dair kesin bir sınır koyar. Bu üç bayrak, curl’ü kullanışlı bir araçtan güvenilir bir araca dönüştürür.
Teorilere başvurmadan önce -v adresine bakın. En şaşırtıcı davranışlar, ne göndermek istediğinizi değil, gerçekte neyin gönderildiğini gördüğünüz anda çözülür.
Kendi ürünümüzde: Yukarıdaki proxy'lerle ilgili bölüm, mekanizmaların gerçekten karmaşık olması nedeniyle yer almaktadır; bir proxy kullanmanız gerektiği için değil. Sıradan API çağrıları, dosya indirmeleri ve küçük işler için basit komuttan başka bir şeye gerek yoktur; bunlara bir proxy eklemek ise gecikmeye ve ek masrafa neden olur. Proxy'lerin gerçekten gerekli olduğu durumlarda — coğrafi kontrol, adres başına hız sınırlarıyla kısıtlanan hacimli işler — sağlayıcıdan daha önemli olan tek ayrıntı, socks5 yerine socks5h kullanmaktır; böylece DNS sorgularınız trafiğinizle aynı rotayı izler.
Tek bir karakter, isteklerinizi yönlendirmekle onları duyurmak arasındaki farkı belirler.
