HTTP

HTTP स्क्रीन एक साथ रिक्वेस्ट इंस्पेक्टर और लोड टूल है:

एक अकेली रिक्वेस्ट भेजें और स्टेटस, उसमें लगा समय, हेडर और बॉडी देखें;
Basic, किसी Bearer टोकन या Digest से प्रमाणित करें;
सर्वर जो कुकीज़ सेट करता है, उन्हें ब्राउज़र की तरह रखें;
वही रिक्वेस्ट एक साथ कई बार भेजें — एक लोड बर्स्ट — और थ्रूपुट तथा लेटेंसी पर्सेंटाइल पढ़ें।

रिक्वेस्ट भेजना

HTTP खोलें।
मेथड चुनें और URL टाइप करें, जैसे http://127.0.0.1:8080/health।
अगर सर्वर को चाहिए तो हेडर जोड़ें; + हेडर एक पंक्ति जोड़ता है, ✕ एक हटाता है। नाम के बिना पंक्ति नहीं भेजी जाती।
GET और HEAD के अलावा किसी मेथड के लिए बॉडी लिखें। GET या HEAD पर जाते समय टेक्स्ट फ़ील्ड में रहता है और दूसरे मेथड के साथ वापस आ जाता है, पर तब तक भेजा नहीं जाता।
भेजें दबाएँ।

बटनों के नीचे की पंक्ति तुरंत फ़ैसला देती है — स्टेटस, समय और आकार, या कोई जवाब क्यों नहीं आया — और रिस्पॉन्स पैनल बाकी दिखाता है। रिक्वेस्ट (मेथड, URL, हेडर, बॉडी, टाइमआउट और कुकी रखें) स्क्रीन बदलने पर और ऐप फिर से शुरू करने पर भी बनी रहती है; क्रेडेंशियल नहीं।

कुंजी	कहाँ	क्या करता है
`Enter`	URL, कोई हेडर, कोई क्रेडेंशियल, टाइमआउट	भेजता है
`Ctrl`+`Enter`	रिक्वेस्ट का कोई भी फ़ील्ड, बॉडी सहित	भेजता है
`Ctrl`+`S`	रिक्वेस्ट का कोई भी फ़ील्ड	इसे सिग्नल के रूप में सहेजता है (नीचे)

रिक्वेस्ट के फ़ील्ड

फ़ील्ड	क्या	डिफ़ॉल्ट
मेथड	GET, POST, PUT, PATCH, DELETE, HEAD या OPTIONS	GET
URL	एक `http://` या `https://` URL	`http://127.0.0.1:8080/`
हेडर	नाम और मान के जोड़े, जैसे लिखे गए वैसे भेजे जाते हैं। अपने `User-Agent` के बिना, Signal Lab `SignalLab/0.1` भेजता है।	`Accept: application/json`
प्रमाणीकरण	रिक्वेस्ट कैसे प्रमाणित होती है (नीचे)	कोई नहीं
कुकी रखें	सर्वर जो कुकीज़ सेट करते हैं, उन्हें वापस भेजें (नीचे)	चालू
बॉडी	ठीक जैसा लिखा है वैसा भेजा जाता है; कोई `Content-Type` नहीं जोड़ा जाता, इसलिए जो मेल खाता हो वह हेडर जोड़ें। ख़ाली बॉडी नहीं भेजी जाती। GET और HEAD के लिए यह फ़ील्ड नहीं दिखता, और तब रिक्वेस्ट कोई बॉडी नहीं ले जाती — न भेजने में, न सहेजे गए सिग्नल में, न प्रयोग में जोड़ें में — भले ही आपने किसी और मेथड के नीचे एक टाइप किया हो।	ख़ाली
टाइमआउट (ms)	पूरा आदान-प्रदान कितनी देर ले सकता है, जवाब और बॉडी सहित	10 000

प्रमाणीकरण

प्रमाणीकरण	फ़ील्ड	क्या भेजा जाता है
कोई नहीं	—	कोई `Authorization` हेडर नहीं
Basic	उपयोगकर्ता नाम, पासवर्ड	`Authorization: Basic …`, नाम और पासवर्ड base64 में, पहली रिक्वेस्ट के साथ
Bearer टोकन	टोकन	`Authorization: Bearer <token>`
Digest	उपयोगकर्ता नाम, पासवर्ड	पहले कुछ नहीं; सर्वर की चुनौती का जवाब (नीचे)

Basic और Digest के बीच बदलने पर नाम और पासवर्ड बने रहते हैं।

Digest

Digest के साथ Signal Lab रिक्वेस्ट बिना क्रेडेंशियल भेजता है। जब सर्वर Digest चुनौती के साथ 401 जवाब देता है, तो Signal Lab चुनौती और आपके पासवर्ड से जवाब निकालता है और रिक्वेस्ट फिर से भेजता है। जो जवाब आप देखते हैं वह उस दूसरी रिक्वेस्ट का होता है, Digest: चैलेंज का जवाब दिया गया से चिह्नित, और लेटेंसी दोनों आदान-प्रदान गिनती है — जितना क्लाइंट प्रतीक्षा करता है।

एल्गोरिदम: MD5 और SHA-256, और उनके -sess रूप। जब सर्वर दोनों पेश करे, SHA-256 उपयोग होता है।
सुरक्षा की गुणवत्ता: auth और auth-int, और qop के बिना पुराना जवाब।
जब सर्वर कहे कि nonce ख़त्म हो गया (stale), या नए के साथ फिर माँगे, तो रिक्वेस्ट का जवाब फिर दिया जाता है, अधिकतम 3 बार और। जब वह अपने पिछले दिए nonce के जवाब को अस्वीकार करे, तो 401 बना रहता है: नाम या पासवर्ड ग़लत है।
रीडायरेक्ट Signal Lab ख़ुद फ़ॉलो करता है, इसलिए जो URL माँगता है उसी का जवाब दिया जाता है। किसी और origin की चुनौती का जवाब नहीं दिया जाता: एक होस्ट के लिए टाइप किए क्रेडेंशियल किसी और के पास नहीं जाते। एक ही होस्ट और डिफ़ॉल्ट पोर्ट पर http:// से https:// पर जाना एक ही होस्ट माना जाता है।

जब चुनौती का जवाब न दिया जा सके, तो 401 बना रहता है और पैनल कारण बताता है:

संदेश	अर्थ
सर्वर ने Digest माँगे बिना 401 लौटाया	सर्वर किसी और स्कीम को चाहता है; Basic या Bearer आज़माएँ।
सर्वर ने … के साथ Digest माँगा	ऐसा एल्गोरिदम जो Signal Lab नहीं बोलता; वह MD5 और SHA-256 बोलता है।
सर्वर ने realm या nonce के बिना Digest माँगा	सर्वर की चुनौती अधूरी है।
रिक्वेस्ट आगे … को भेजी गई, जिसने Digest माँगा	कोई रीडायरेक्ट किसी और origin तक ले गया, जिसकी चुनौती का जवाब नहीं दिया जाता।

क्रेडेंशियल कहाँ जाते हैं

क्रेडेंशियल केवल रिक्वेस्ट के Authorization हेडर में जाते हैं, भेजे जाते समय। इंस्पेक्टर, कंसोल और प्रयोग की रिपोर्टें वह हेडर कभी नहीं दिखातीं। इस स्क्रीन पर वे केवल मेमोरी में रखे जाते हैं और रीस्टार्ट के बाद चले जाते हैं — सिवाय तब जब रिक्वेस्ट किसी सहेजे गए सिग्नल से जुड़ी हो, जो उन्हें वापस ले आता है।

WARNING

सिग्नल के रूप में सहेजी गई रिक्वेस्ट अपने क्रेडेंशियल लाइब्रेरी फ़ाइल signals.json में सादे टेक्स्ट के रूप में रखती है। किसी प्रयोग में पासवर्ड के बजाय {{secret.NAME}} लिखें; देखें डेटा और टेम्पलेट।

कुकीज़

कुकी रखें चालू होने पर, जो सर्वर Set-Cookie से सेट करता है वह स्क्रीन के कुकी जार में रखा जाता है और उस सर्वर को बाद की रिक्वेस्टों के साथ वापस भेजा जाता है, ब्राउज़र के नियमों का पालन करते हुए (डोमेन, पाथ, Secure, समाप्ति)। जार इस स्क्रीन की रिक्वेस्टें, इसका बर्स्ट और लाइब्रेरी से आप जो HTTP सिग्नल भेजते हैं, उपयोग करते हैं। कुकीज़ के बिना रिक्वेस्ट भेजने और कोई न रखने के लिए इसे बंद करें।

रिक्वेस्ट और रिस्पॉन्स के नीचे का कुकीज़ पैनल बताता है कि जार में क्या है: नाम, मान, डोमेन और पाथ (. से शुरू होने वाला डोमेन उसके सबडोमेन को भी कवर करता है), समाप्ति (बिना समाप्ति वाली कुकी के लिए सत्र के साथ) और फ़्लैग (Secure, HttpOnly, SameSite)। समाप्त हो चुकी कुकीज़ सूचीबद्ध नहीं होतीं। साफ़ करें जार ख़ाली कर देता है।

जार ऐप जितनी देर जीवित रहती है: रीस्टार्ट एक ख़ाली के साथ शुरू होता है। किसी सर्वर पर, उसमें साइन इन हर पेज के लिए एक जार होता है। एक प्रयोग रन का अपना जार होता है (देखें प्रयोग), और signallab send http कोई नहीं उपयोग करता।

रिस्पॉन्स

हिस्सा	क्या
स्टेटस	स्टेटस कोड और उसका कारण; `ERR` जब कोई जवाब न आया
लेटेंसी	भेजने से लेकर बॉडी के अंतिम बाइट तक, मिलीसेकंड में
आकार	बॉडी का आकार
रिस्पॉन्स हेडर	उन्हें दिखाने या छिपाने के लिए उनकी गिनती वाली पंक्ति पर क्लिक करें
बॉडी	JSON होने पर फ़ॉर्मैट की हुई; रॉ दिखाएँ और JSON फ़ॉर्मेट करें बदलते हैं। अधिकतम 256 KiB दिखाया जाता है, फिर `… (truncated)`।

जब कोई जवाब न हो, तो पैनल कारण बताता है, उन्हीं शब्दों में जो Signal Lab में हर जगह हैं: अस्वीकार, समय में कोई जवाब नहीं, नाम रिज़ॉल्व नहीं होता, प्रमाणपत्र की समस्या और इसी तरह। सिस्टम से आया तकनीकी विवरण उसके नीचे मोड़ दिया जाता है।

रीडायरेक्ट

रीडायरेक्ट (301, 302, 303, 307, 308) फ़ॉलो किए जाते हैं, अधिकतम 10; दिखाया गया जवाब अंतिम होता है। 301, 302 और 303 के बाद रिक्वेस्ट बिना बॉडी के GET के रूप में जाती है (HEAD, HEAD रहता है); 307 और 308 के बाद जैसी थी वैसी। एक होस्ट के लिए टाइप किए Authorization और कुकीज़ किसी और के पास नहीं भेजे जाते।

सुरक्षित कनेक्शन

https:// सर्वर का प्रमाणपत्र उन प्रमाणपत्रों के विरुद्ध जाँचा जाता है जिन पर यह सिस्टम भरोसा करता है। स्व-हस्ताक्षरित या समाप्त प्रमाणपत्र "A secure connection to … could not be made" के साथ अस्वीकार कर दिया जाता है; जाँच छोड़ने का कोई सेटिंग नहीं है। अपने प्रमाणपत्र वाले सर्वर को परखने के लिए, उसे सिस्टम के भरोसेमंद प्रमाणपत्रों में जोड़ें।

लोड बर्स्ट

लोड बर्स्ट स्क्रीन पर की रिक्वेस्ट — उसके प्रमाणीकरण और, जब तक कुकी रखें चालू है, कुकी जार के साथ — कई बार भेजता है, और उसे मापता है।

कॉन्करेंसी, कुल, अवधि, s और दर, req/s सेट करें।
बर्स्ट शुरू करें दबाएँ। बर्स्ट एक जॉब है: बर्स्ट रोकें, या कंसोल पट्टी में उसे रोकना, इसे समाप्त कर देता है।

फ़ील्ड	क्या	डिफ़ॉल्ट
कॉन्करेंसी	एक साथ उड़ान में रिक्वेस्ट, 1–512	20
कुल	भेजने की रिक्वेस्ट; 0 — अवधि ख़त्म होने तक भेजते रहें	500
अवधि, s	चलने के सेकंड; 0 — कुल भेजे जाने पर रुकें	0
दर, req/s	प्रति सेकंड शुरू होने वाली रिक्वेस्ट, 0.1–100 000; 0 — जितना तेज़ कर्मचारी जाएँ	0

कुल और अवधि, s दोनों 0 होने पर, बर्स्ट तब तक चलता है जब तक आप उसे रोकें।

भेजने के दो तरीके हैं:

दर, req/s 0. हर कर्मचारी जवाब मिलते ही फिर भेजता है। यह पता लगाता है कि सर्वर कितना लेता है, पर धीमा सर्वर बर्स्ट को भी धीमा कर देता है।
एक दर। रिक्वेस्ट तय समय-सारणी पर शुरू होती हैं — 10 प्रति सेकंड पर, शुरू से हर 100 ms में एक — जवाब चाहे कितने भी धीमे हों। जिस रिक्वेस्ट का समय तब आता है जब हर कर्मचारी व्यस्त हो, वह एक के लिए अधिकतम 50 ms प्रतीक्षा करती है; उसके बाद उसे छोड़ दिया जाता है और छूटे के रूप में गिना जाता है, कभी देर से नहीं भेजा जाता। छूटी रिक्वेस्ट का अर्थ है कि इस दर के लिए concurrency बहुत कम है, या सर्वर उस दर की ज़रूरत से धीमा है।

संख्या	क्या
भेजे गए	जिन रिक्वेस्ट का जवाब आ चुका या जो विफल हुईं
OK	2xx स्टेटस से जवाब पाने वाली
विफल	कोई जवाब नहीं, या 200–299 से बाहर कोई भी स्टेटस
छूटे	छोड़ी गईं, जैसा ऊपर (केवल दर के साथ)
RPS	पिछले दसवें सेकंड में प्रति सेकंड रिक्वेस्ट; बर्स्ट समाप्त होने पर पूरे बर्स्ट में। दर के साथ, लेबल माँगी गई दर बताता है।
p50, p90, p95, p99	वह समय जिसके भीतर रिक्वेस्ट का वह हिस्सा पूरा हुआ, विफलताएँ सहित; 0.5 % के भीतर सटीक
औसत, न्यूनतम, अधिकतम	औसत, सबसे तेज़ और सबसे धीमा

संख्याएँ लगभग 10 बार प्रति सेकंड अपडेट होती हैं। उनके बगल का चार्ट पिछले लगभग 24 सेकंड में प्रति सेकंड रिक्वेस्ट खींचता है।

Digest के साथ, पहली रिक्वेस्ट की चुनौती का जवाब एक बार दिया जाता है और वह जवाब बर्स्ट की हर रिक्वेस्ट के लिए काम करता है।

WARNING

बर्स्ट असली लोड है। इसे केवल उन सर्वरों की ओर मोड़ें जो आपके हैं या जिन्हें परखने की आपको अनुमति है।

रैंप, चरण, स्पाइक और पास/फ़ेल थ्रेशोल्ड के लिए, रिक्वेस्ट को प्रयोग में लोड के अंतर्गत चलाएँ।

इंस्पेक्टर में

कैप्चर चालू रहते, हर आदान-प्रदान प्रोटोकॉल http और स्रोत http वाला एक फ़्रेम बनकर दिखता है: सारांश में मेथड, URL, स्टेटस और समय, इसके विवरण में रिस्पॉन्स हेडर और बॉडी की शुरुआत (2000 अक्षर), फ़ैसले के रूप में स्टेटस (failed जब कोई जवाब न आया, · digest after 401 जब किसी चुनौती का जवाब दिया गया)। फ़्रेम बॉडी का आकार दर्ज करता है, उसके बाइट नहीं। रिक्वेस्ट का Authorization हेडर उसमें कभी नहीं होता। एक बर्स्ट कैप्चर में हर 100 ms में अधिकतम एक आदान-प्रदान डालता है। देखें इंस्पेक्टर।

सहेजना और दोबारा उपयोग

सिग्नल के रूप में सहेजें। सहेजें… रिक्वेस्ट को — मेथड, URL, हेडर, बॉडी, टाइमआउट और प्रमाणीकरण — सिग्नल लाइब्रेरी में रखता है। स्क्रीन उससे जुड़ी रहती है: सहेजें (Ctrl+S) उसे अपडेट करता है, इस रूप में सहेजें… उसकी कॉपी बनाता है, चिप उसे सिग्नल में खोलती है। लाइब्रेरी से कोई HTTP सिग्नल खोलने पर वह क्रेडेंशियल सहित यहाँ वापस लोड होता है। देखें सिग्नल।
किसी प्रयोग में जोड़ें। प्रयोग में जोड़ें खुले प्रयोग में उसी रिक्वेस्ट वाला एक HTTP रिक्वेस्ट चरण जोड़ता है, End से ठीक पहले या चुने गए चरण के बाद, और उसे खोल देता है।
इसका मॉक बनाएँ। किसी रिस्पॉन्स के नीचे, इसका मॉक बनाएँ एक एमुलेटर रूट बनाता है जो इस मेथड और पाथ का जवाब इस स्टेटस, हेडर और बॉडी से देता है। इसमें जोड़ें में कोई HTTP एमुलेटर चुनें, या नया एमुलेटर, और रूट जोड़ें दबाएँ; रूट उस एमुलेटर में सबसे पहले जाता है, और एमुलेटर स्क्रीन उसी पर खुलती है। देखें एमुलेटर।

प्रयोगों में

चरण	क्या करता है
HTTP रिक्वेस्ट	एक रिक्वेस्ट भेजता है; इसका URL, हेडर, बॉडी और क्रेडेंशियल `{{templates}}` लेते हैं। यह लोड के अंतर्गत चल सकता है। विवरण
HTTP स्टेटस, रिस्पॉन्स टेक्स्ट, रिस्पॉन्स हेडर, रिस्पॉन्स समय	नवीनतम रिस्पॉन्स जाँचते हैं। विवरण
मान निकालें	किसी JSON फ़ील्ड, हेडर, स्टेटस, बॉडी या रेगुलर एक्सप्रेशन के मिलान को वेरिएबल के रूप में रखता है। विवरण
स्टेटस पर शाखा	स्टेटस के अनुसार Yes या No से आगे बढ़ता है। विवरण
HTTP रिक्वेस्ट की प्रतीक्षा	रन के अपने listener या एमुलेटर पर कोई रिक्वेस्ट आने की प्रतीक्षा करता है — उस सिस्टम से जिसे आप परखते हैं। विवरण
एमुलेटर	एक HTTP API जो पूरे रन के लिए रूटों से जवाब देता है। विवरण

कमांड लाइन से

signallab send http इस स्क्रीन की तरह एक रिक्वेस्ट भेजता है:

bash

signallab send http GET http://127.0.0.1:8080/health --expect-status 200
signallab send http POST http://127.0.0.1:8080/api/items \
  -H 'Content-Type: application/json' --body '{"name":"lamp"}'
signallab send http GET http://127.0.0.1:8080/private -u admin:secret --digest

स्टेटस पंक्ति standard error पर जाती है और बॉडी standard output पर:

text

HTTP 200 OK · 3 ms · 15 B
{"status":"ok"}

विकल्प	क्या	डिफ़ॉल्ट
`-H`, `--header 'Name: value'`	एक हेडर; और के लिए दोहराएँ	—
`--body TEXT`, `--body @FILE`	बॉडी, या किसी फ़ाइल की सामग्री	—
`--expect-status N`	स्टेटस N न हो तो exit 1	—
`--timeout MS`	जवाब के लिए कितनी देर प्रतीक्षा करें	10 000
`-u`, `--user NAME:PASSWORD`	Basic प्रमाणीकरण	—
`--digest`	`--user` के साथ: इसके बजाय सर्वर की Digest चुनौती का जवाब दें	—
`--bearer TOKEN`	`Authorization: Bearer TOKEN`	—
`--json`	पूरा रिस्पॉन्स standard output पर JSON के रूप में छापें	—

यह 0 के साथ निकलता है जब कोई जवाब आया (और अपेक्षित स्टेटस था), 1 जब कोई नहीं आया, स्टेटस अपेक्षित नहीं था या Digest चुनौती का जवाब नहीं दिया जा सका, और 2 जब कोई विकल्प अमान्य हो। यह कोई कुकीज़ नहीं रखता। देखें कमांड लाइन।

समस्याएँ

जो आप देखते हैं	सामान्य कारण
`… refused the connection — nothing is listening on that port`	सर्वर चल नहीं रहा, या किसी और पोर्ट या पते पर सुनता है।
`No answer from … in time`	सर्वर धीमा या अनुपलब्ध है; पता जाँचें, या टाइमआउट (ms) बढ़ाएँ।
`Cannot resolve …`	होस्ट नाम इस मशीन पर रिज़ॉल्व नहीं होता — कोई टाइपो, या ऐसा नाम जिसे केवल कोई और नेटवर्क जानता है।
`A secure connection to … could not be made`	प्रमाणपत्र यहाँ भरोसेमंद नहीं है (स्व-हस्ताक्षरित, समाप्त, दूसरा नाम), या TLS विफल हुआ। देखें सुरक्षित कनेक्शन।
`… is not a valid address`	URL ख़राब है या `http://` या `https://` से शुरू नहीं होता।
सर्वर कहता है बॉडी ग़ायब है या ग़लत प्रकार की	बॉडी से मेल खाता कोई `Content-Type` हेडर नहीं, या ख़ाली बॉडी।
Digest के साथ `401`	स्टेटस के नीचे का संदेश पढ़ें: देखें Digest।
छूटे 0 से ऊपर	कॉन्करेंसी बढ़ाएँ, या दर घटाएँ: सर्वर दर की ज़रूरत से धीमा जवाब देता है।
सर्वर जवाब देता है फिर भी विफल ऊँचा	200–299 से बाहर हर स्टेटस विफल गिना जाता है, 404 और 500 सहित।

सर्वर पर, रिक्वेस्ट सर्वर से बाहर जाती हैं: 127.0.0.1 सर्वर ही है। देखें सर्वर।

हर त्रुटि संदेश त्रुटि संदेश में सूचीबद्ध है।

HTTP ​

रिक्वेस्ट भेजना ​

रिक्वेस्ट के फ़ील्ड ​

प्रमाणीकरण ​

Digest ​

क्रेडेंशियल कहाँ जाते हैं ​

कुकीज़ ​

रिस्पॉन्स ​

रीडायरेक्ट ​

सुरक्षित कनेक्शन ​

लोड बर्स्ट ​

इंस्पेक्टर में ​

सहेजना और दोबारा उपयोग ​

प्रयोगों में ​

कमांड लाइन से ​

समस्याएँ ​