مُجمِع استجابة HTTP المُصطنع
مرشد
مُجمِع استجابة HTTP المُصطنع
بناء رسالة استجابة HTTP من حيث البنية في ثوانٍ. اختر كود الحالة، اختر نوع الجسم، أضف رؤوسًا، ثم يُصدر الأداة نصًا جاهزًا للنسخ يحتوي على سطر الحالة، الرؤوس، والجسم، مفصّلًا بـ CRLF — مثالي للإمكانيات التجريبية، المocks، ووثائق API، وتشغيل الاستجابات ضد العملاء.
كيفية استخدام
- اختر نسخة HTTP (تُستخدم الافتراضية HTTP/1.1) و كود الحالة من مُختار مُجمّع — على سبيل المثال
200 OK,404 Not Found، أو503 Service Unavailable. - (اختياري) تغيير مُصطلح السبب إذا كنت بحاجة إلى نص غير معياري بعد كود الحالة.
- اختر نوع الجسم (نص بسيط، JSON، XML، HTML، نموذج، أو لا شيء) ونُسخ أو أدخل الجسم.
- تبديل تلقائيًا نوع المحتوى, تلقائيًا طول المحتوىو، و تاريخ رؤوس تتماشى مع طريقة استجابة الخادم.
- أضف أي رؤوس إضافية — اختر من الرؤوس الشائعة (Cache-Control، ETag، Set-Cookie، CORS، رؤوس الحد الأقصى) أو أدخل زوج اسم/قيمة مخصص.
- نسخ الاستجابة الكاملة، نسخ الرؤوس فقط، أو تنزيلها كـ
.httpملف لاستخدامه في أدوات REST، أو مُدخلات، أو أدوات إعادة التشغيل.
خصائص
- مُختار مُجمّع لكود الحالة – الكودات الشائعة من 1xx إلى 5xx مُصنّفة حسب الفئة، كل منها يحتوي على مصطلح سبب معياري.
- مُختار نوع الجسم – يملأ تلقائيًا نوع المحتوى المناسب (application/json، text/html، application/xml، application/x-www-form-urlencoded، text/plain) لضمان توازن الرؤوس والجسم.
- تلقائيًا طول المحتوى – يُعدّ عدد الأحرف (ليس الأحرف) باستخدام ترميز UTF-8، مما يتوافق مع طريقة حساب الخوادم الحقيقية.
- رأس التاريخ المُصاغ من قبل IMF – يُنتج وقتًا متوافقًا مع المعيار (مثلاً
Sun, 06 Nov 1994 08:49:37 GMT) للحظة الحالية. - رؤوس الاستجابة الشائعة – مُصادر بسيطة لـ Cache-Control، ETag، Expires، Last-Modified، Location، Server، Set-Cookie، Vary، WWW-Authenticate، Access-Control-Allow-Origin، X-RateLimit، وX-Powered-By.
- رؤوس مخصصة – أضف أي زوج اسم/قيمة، مع عرض تجريبي للاستجابة المُجمعة.
- أوجه إخراج مُتعددة – الاستجابة الكاملة (السطر المُحدد + الرؤوس + سطر فارغ + الجسم) ورؤوس فقط — نسخ أي منها، أو تنزيل الاستجابة الكاملة كـ
response.http. - مُتّسق مع المعيار في السطر – يستخدم CRLF (
\r\n) بين السطور، وهو المُطلوب من قبل RFC 9112. - تحديثات حية – كل تغيير يُعيد حساب الناتج فورًا؛ لا حاجة لزر "إرسال" أو "تثبيت".
- يُشغل بالكامل في المتصفح الخاص بك – لا تُخرج أي بيانات من جهازك ولا يُستخدم خادم خلفي.
حالات الاستخدام الشائعة
- مُدخلات اختبار وتكامل – نسخ الناتج إلى مُدخلة نصية لـ
requests-mock,nock، MSW، WireMock، أو أي مُسجل HTTP. - وثائق API – عرض شكل دقيق للإجابة (مع الرؤوس) في أمثلة OpenAPI أو الوثائق المُقدمة للعملاء.
- تصحيح العملاء – إعادة إنتاج استجابة خادم نادرة (مُحددة السرعة، محتوى جزئي، إعادة توجيه) دون الحاجة لتشغيل خادم حقيقي.
- تعليم HTTP – توضيح صيغة الرسالة على الوجهة: سطر الحالة، الرؤوس، سطر فارغ، الجسم.
- إعادة تشغيل يدويًا – توصيل الاستجابة إلى
nc -lأو مُستمع مشابه لاختبار كيفية استجابة العميل.
التعليمات
-
ما هي بنية رسالة استجابة HTTP/1.1؟
تتكون استجابة HTTP/1.1 من سطر الحالة، صفر أو أكثر من حقول الرؤوس، سطر فارغ، وجسم اختياري. يُشكل سطر الحالة من نسخة HTTP، كود الحالة الثلاثي الأرقام، ومصطلح السبب، مفصّلًا بمسافات واحدة. يتم إنهاء كل سطر بـ CRLF (العودة + التبديل). يُحدد السطر الفارغ بعد آخر رأس بداية الجسم. هذه البنية مُحددة في RFC 9112 (الناقل لـ RFC 7230).
-
ما الذي يقيسُه Content-Length، الأحرف أم الأحرف؟
يُقيس Content-Length طول الجسم بالأوكتيتس (البايت)، وليس الأحرف. في النصوص باللغة الإنجليزية، يتطابق القيمتان، لكن في أي نص UTF-8 يحتوي على أحرف غير إنجليزية، يختلف القيمتان — غالبًا يستخدم كل علامة تعبير أو حرف مُحَوَّل 2–4 بايت. حساب Content-Length من عدد الأحرف في سلسلة نصية هو أحد الأخطاء الشائعة في HTTP، مما يؤدي إلى تقصير الجسم أو توقف العميل في انتظار بايتس مفقودة.
-
ما الفرق بين إعادة توجيه 301 و302؟
تتضمن كلا الاستجابتين رأسًا يُشير إلى عنوان جديد، لكن المعاني مختلفة. يُخبر 301 Moved Permanently العميل والمحركات البحثية أن المورد تم نقله بشكل دائم، لذا قد يُستبدَل العنوان الأصلي في المحفوظات والروابط. يُشير 302 Found (أصلًا "Moved Temporarily") إلى إعادة توجيه مؤقتة — يجب استخدام العنوان الأصلي في المستقبل. بالنسبة للإعادة التوجيهات التي تُحافظ على طريقة الطلب، يُفضل عادةً 308 (دائم) و307 (مُؤقت) بدلًا من 301 و302.
-
هل يستخدم HTTP/2 سطر الحالة ونص السبب؟
يحتفظ HTTP/2 بـ كود الحالة الرقمي، لكنه يُزيل نص السبب تمامًا. يتم توصيل الحالة كمجال خيالي (:status: 200)، والبروتوكول مُفرّم بتنسيق ثنائي بدلًا من نص مُكتوب. يبقى نص السبب فقط في HTTP/1.x وله طبيعة معلوماتية — يجب على العميل أن يُؤثر على كود الحالة، وليس النص.
-
لماذا يتطلب HTTP CRLF بدلًا من مجرد خط جديد؟
تُورث تقنية إنهاء السطر في HTTP من البروتوكولات النصية القديمة (SMTP، NNTP، FTP) المُعرّفة في السبعينيات، والتي تستخدم CRLF (\r\n) كنقطة نهاية سطر معيارية. تتطلب المُصطلحات في RFC 9112 أن يكون CRLF بين سطر البداية، حقول الرؤوس، وسطر فارغ قبل الجسم. تكون معظم الخوادم مُتقبلة للخط الفارغ، لكن المُحلّلين الصارمين والمعاينات قد ترفض الاستجابات التي تُغفل العودة.
تثبيت ملحقاتنا
أضف أدوات IO إلى متصفحك المفضل للوصول الفوري والبحث بشكل أسرع
恵 وصلت لوحة النتائج!
لوحة النتائج هي طريقة ممتعة لتتبع ألعابك، يتم تخزين جميع البيانات في متصفحك. المزيد من الميزات قريبا!
