বিনামূল্যে HTTP স্ট্যাটাস কোড রেফারেন্স

Expect: 100-continue সহ অনুরোধের জন্য ব্যবহৃত। ক্লায়েন্ট বডি পাঠানোর আগে সার্ভার জানায় যে সে তা গ্রহণ করতে ইচ্ছুক। আধুনিক ওয়েব অ্যাপ্লিকেশনে খুব কমই দেখা যায়।

সবচেয়ে সাধারণত WebSocket আপগ্রেডের জন্য ব্যবহৃত — ক্লায়েন্ট Upgrade: websocket অনুরোধ করে এবং সার্ভার সুইচ করতে 101 দিয়ে প্রতিক্রিয়া করে।

দীর্ঘ অপারেশনের সময় ক্লায়েন্ট টাইমআউট প্রতিরোধ করার জন্য পাঠানো একটি WebDAV অন্তর্বর্তী প্রতিক্রিয়া। অবহেলিত — আধুনিক সার্ভারগুলি এটি পাঠানো উচিত নয়।

সার্ভারগুলিকে লিঙ্ক হেডার (প্রিলোড/প্রিসংযোগ) পাঠাতে দেয় যখন চূড়ান্ত প্রতিক্রিয়া এখনো প্রস্তুত করা হচ্ছে, তাই ব্রাউজারগুলি গুরুত্বপূর্ণ সম্পদ দ্রুত আনতে শুরু করতে পারে।

মান সফলতা প্রতিক্রিয়া। অর্থ HTTP পদ্ধতির উপর নির্ভর করে: GET → রিসোর্স ফেরত দেওয়া হয়েছে, POST/PUT → পদক্ষেপ সম্পূর্ণ।

একটি POST এর পরে সাধারণ। প্রতিক্রিয়ায় নতুন সম্পদের URL-এর দিকে নির্দেশ করা একটি Location হেডার অন্তর্ভুক্ত থাকা উচিত।

অ্যাসিঙ্ক অপারেশনের জন্য — সার্ভার কাজ সারিবদ্ধ করছে। ক্লায়েন্ট একটি স্ট্যাটাস এন্ডপয়েন্ট পোল করা বা পরে ফিরে আসা উচিত।

অনুরোধ সফল হয়েছে, কিন্তু একটি মধ্যস্থতাকারী (যেমন একটি ক্যাশিং বা রূপান্তরকারী প্রক্সি) উৎস সার্ভার থেকে পেলোড পরিবর্তন করেছে — উদাহরণ স্বরূপ, ছবি পুনরায় সংকুচিত করা। অনুশীলনে বিরল।

প্রায়ই DELETE অপারেশন বা PUT আপডেটের জন্য ব্যবহৃত যা বডি ফেরত দেওয়ার প্রয়োজন নেই। ক্লায়েন্ট বর্তমান পৃষ্ঠা থেকে দূরে যাওয়া উচিত নয়।

204 এর মতো, কোনো বডি ফেরত দেওয়া হয় না — কিন্তু ক্লায়েন্টকে অতিরিক্তভাবে অনুরোধ তৈরি করেছে এমন ফর্ম বা ভিউ রিসেট করতে বলা হয় (যেমন পরবর্তী এন্ট্রির জন্য ফর্ম ফিল্ডগুলি সাফ করুন)।

একটি Range অনুরোধের প্রতিক্রিয়া। ভিডিও প্লেয়ার এবং ডাউনলোড ম্যানেজারগুলি দ্বারা বাধিত ডাউনলোড পুনরায় শুরু করতে বা বড় ফাইলগুলি স্ট্রিম করতে ব্যবহৃত হয়।

WebDAV: একটি XML বডি একাধিক সাব-অপারেশনের ফলাফল স্বাধীনভাবে রিপোর্ট করে — যেমন একটি ব্যাচ সরানো যেখানে কিছু আইটেম সফল হয়েছে এবং অন্যরা ব্যর্থ হয়েছে।

WebDAV: 207 মাল্টি-স্ট্যাটাস প্রতিক্রিয়ার মধ্যে ব্যবহৃত হয় একই সংগ্রহের সদস্যদের বারবার তালিকা এড়াতে যখন বাঁধনগুলি লুপ তৈরি করে।

ডেল্টা এনকোডিং: সার্ভার সম্পূর্ণ সম্পদের পরিবর্তে একটি পূর্ববর্তী সংস্করণের বিরুদ্ধে একটি পার্থক্য ফেরত দেয়, ব্যান্ডউইথ সঞ্চয় করে। খুবই দুর্লভভাবে বাস্তবায়িত।

সার্ভার একাধিক বিকল্প অফার করে (যেমন বিভিন্ন ফর্ম্যাট বা ভাষা) এবং ক্লায়েন্ট একটি বেছে নেয়। খুব কমই ব্যবহৃত হয়, কারণ স্বয়ংক্রিয় কন্টেন্ট আলোচনা সাধারণত এটি পরিচালনা করে।

স্থায়ী URL পরিবর্তনের জন্য ব্যবহার করুন — অনুসন্ধান ইঞ্জিনগুলি তাদের সূচক আপডেট করবে। SEO কর্তৃত্ব নতুন URL তে স্থানান্তরিত হয়।

পুনর্নির্দেশ স্থায়ী নয় তা নির্দেশ করে। ক্যাশিং 301 এর চেয়ে কম আক্রমণাত্মক। 'লগইন প্রয়োজন, /login এ পুনর্নির্দেশ করা হচ্ছে' এর মতো জিনিসগুলির জন্য ব্যবহার করুন।

POST জমা দেওয়ার পরে ব্যবহৃত হয় — প্রতিক্রিয়া বলে 'আপনার POST কাজ করেছে, ফলাফলের জন্য এই GET URL দেখুন'। ব্রাউজারগুলি সর্বদা নতুন URL GET করে।

একটি শর্তাধীন অনুরোধের প্রতিক্রিয়া (If-None-Match বা If-Modified-Since হেডার সহ)। ব্যান্ডউইথ সঞ্চয় করে — কোনো বডি ফেরত দেওয়া হয় না।

যদি মূল POST হয়, পুনর্নির্দেশও POST ব্যবহার করে। পদ্ধতি সংরক্ষণ গুরুত্বপূর্ণ হলে 302 এর আধুনিক বিকল্প।

301 এর আধুনিক প্রতিস্থাপন যখন আপনি চান পুনর্নির্দেশের পরে POST অনুরোধগুলি POST থেকে যাক।

সাধারণ কারণ: বডিতে ত্রুটিপূর্ণ JSON, অবৈধ কোয়েরি প্যারামিটার, বা প্রয়োজনীয় ক্ষেত্র অনুপস্থিত। অনুরোধ বডি এবং হেডার পরীক্ষা করুন।

ক্লায়েন্টকে প্রমাণীকরণ শংসাপত্র অন্তর্ভুক্ত করতে হবে (Authorization হেডার, কুকি, টোকেন)। 'অননুমোদিত' একটি ভুল নাম — এটি সত্যিই 'অপ্রমাণিত' অর্থ।

মূলত ডিজিটাল পেমেন্টের জন্য উদ্দেশ্যযুক্ত। আধুনিক ব্যবহার: API গুলি কখনও কখনও 402 ফেরত দেয় যখন একজন ব্যবহারকারী তাদের পেইড কোটা অতিক্রম করেছে।

401 থেকে ভিন্ন — ব্যবহারকারী লগ ইন করা আছে, কিন্তু তাদের অ্যাকাউন্টের এই সম্পদের জন্য অনুমতি নেই। ভূমিকা/অনুমতি লজিক পরীক্ষা করুন।

হয় URL ভুল, সম্পদ মুছে ফেলা হয়েছে, বা এটি কখনো বিদ্যমান ছিল না। সার্ভারগুলি কখনও 404 ফেরত দেয় যে একটি 403 আরও যথাযথ হত তা লুকাতে।

উদাহরণস্বরূপ, একটি GET অনুরোধ একটি এন্ডপয়েন্টে যা শুধুমাত্র POST গ্রহণ করে। প্রতিক্রিয়ায় বৈধ পদ্ধতিগুলি তালিকাভুক্ত করে একটি Allow হেডার অন্তর্ভুক্ত থাকা উচিত।

ক্লায়েন্ট একটি কন্টেন্ট টাইপ, ভাষা, বা এনকোডিং অনুরোধ করেছে (Accept, Accept-Language, Accept-Encoding এর মাধ্যমে) যা সার্ভার সন্তুষ্ট করতে পারে না। অনেক সার্ভার কঠোর আলোচনা এড়িয়ে যায় এবং পরিবর্তে একটি ডিফল্ট ফেরত দেয়।

401 এর মতো, কিন্তু একটি প্রক্সি দ্বারা জারি: ক্লায়েন্টকে Proxy-Authorization শংসাপত্র পাঠাতে হবে। কর্পোরেট নেটওয়ার্কে প্রমাণীকারী প্রক্সিগুলির সাথে দেখা যায়।

ক্লায়েন্ট অনুরোধ বডি পাঠাতে অত্যধিক সময় নিয়েছে বা সংযোগ নিষ্ক্রিয় রেখেছে। অনুরোধটি আবার চেষ্টা করুন।

সাধারণত একযোগে সম্পাদনা বিরোধ বা নকল সম্পদ তৈরির জন্য প্রতিফলিত হয় (যেমন, এমন একটি ইমেল দিয়ে ব্যবহারকারী তৈরি করা যা ইতিমধ্যে বিদ্যমান)।

404 এর চেয়ে শক্তিশালী — সার্ভার স্পষ্টভাবে জানে যে সম্পদটি আগে বিদ্যমান ছিল কিন্তু চিরস্থায়ীভাবে সরানো হয়েছে। অনুসন্ধান ইঞ্জিনগুলি তালিকাভুক্তি বাতিল করবে।

অনুরোধটি প্রত্যাখ্যান করা হয়েছে কারণ এতে Content-Length হেডার নেই এবং সার্ভার অজানা আকারের বডিগুলি প্রত্যাখ্যান করে। হেডারটি যোগ করুন এবং পুনরায় চেষ্টা করুন।

শর্তাধীন হেডারগুলি যেমন If-Match বা If-Unmodified-Since ব্যর্থ হলে প্রতিফলিত হয় — সাধারণত আশাবাদী লক করা: অন্য কেউ আপনার সংস্করণ থেকে সম্পদটি পরিবর্তন করেছে। পুনরুদ্ধার করুন এবং পুনরায় চেষ্টা করুন।

বড় ফাইলগুলি আপলোড করার সময় সাধারণ। সার্ভার কনফিগ (nginx, apache) সর্বাধিক বডি আকার সেট করে। সার্ভারের কনফিগারেশন চেক করুন।

সাধারণত খুব দীর্ঘ কোয়েরি স্ট্রিং দ্বারা সৃষ্ট হয় (যেমন GET এ ডেটা এনকোডিং)। POST বডিতে সুইচ করুন, বা সার্ভার সীমা বৃদ্ধি করুন যদি আপনি এটি নিয়ন্ত্রণ করেন।

উদাহরণস্বরূপ, application/xml একটি সার্ভারে পাঠানো যা শুধুমাত্র application/json গ্রহণ করে। Content-Type হেডারটি সঠিকভাবে সেট করুন।

Range হেডার ফাইলটি যে অংশটি নেই তা জিজ্ঞাসা করে — যেমন ফাইলের শেষ অতিক্রম করে একটি ডাউনলোড পুনরায় শুরু করা। প্রতিক্রিয়ায় প্রকৃত আকারের সাথে Content-Range অন্তর্ভুক্ত থাকা উচিত।

সার্ভার Expect: 100-continue সমর্থন না করলে পাঠানো হয়। কিছু ক্লায়েন্ট বড় POSTs এ ডিফল্টভাবে এই হেডারটি পাঠায়; এটি অক্ষম করা সাধারণত ত্রুটি সমাধান করে।

1998 সালের একটি এপ্রিল মূর্খতার দিন (RFC 2324)। কিছু আসল API এটি বিদ্রূপ বা অপ্রচলিত এন্ডপয়েন্ট চিহ্নিত করতে ব্যবহার করে। উত্পাদন ব্যবহারের জন্য নয়।

HTTP/2 সংযোগ পুনঃব্যবহারের সাথে সাধারণ: অনুরোধটি এমন একটি সার্ভারে পৌঁছেছে যা লক্ষ্য হোস্টনামের জন্য কনফিগার করা হয়নি। ক্লায়েন্টকে একটি নতুন সংযোগে পুনরায় চেষ্টা করা উচিত।

উদাহরণস্বরূপ, JSON সঠিকভাবে পার্স করা হয়েছে কিন্তু একটি প্রয়োজনীয় ক্ষেত্র অনুপস্থিত ছিল, বা একটি ক্ষেত্র মান পরিসীমার বাইরে ছিল। REST API বৈধতা প্রতিক্রিয়ায় সাধারণ।

WebDAV: উৎস বা গন্তব্য সম্পদ অন্য ক্লায়েন্ট দ্বারা লক করা হয়েছে, তাই অপারেশন এগিয়ে যেতে পারে না। লক প্রকাশিত হওয়ার জন্য অপেক্ষা করুন বা উপযুক্ত টোকেন দিয়ে এটি ভাঙুন।

WebDAV: নির্ভরশীল ক্রিয়াকলাপের একটি শৃঙ্খলে, একটি পূর্ববর্তী ক্রিয়া ব্যর্থ হয়েছে, তাই এটি সম্পাদিত হয়নি। মূল কারণের জন্য পূর্ববর্তী ব্যর্থতা দেখুন।

TLS 1.3 0-RTT (প্রাথমিক ডেটা) সম্পর্কিত: সার্ভার একটি সম্ভবত পুনরাবৃত্তি করা অনুরোধ প্রক্রিয়াকরণ ঝুঁকি নেবে না। ক্লায়েন্টকে হ্যান্ডশেক সম্পূর্ণ হওয়ার পরে পুনরায় চেষ্টা করা উচিত।

সার্ভার বর্তমান প্রোটোকলের উপর অনুরোধ পরিবেশন করতে অস্বীকার করে কিন্তু একটি আপগ্রেডের পরে — প্রতিক্রিয়ায় একটি Upgrade হেডার রয়েছে যা প্রয়োজনীয় প্রোটোকল নাম দেয়।

সার্ভার হারিয়ে যাওয়া আপডেট বিরোধ প্রতিরোধের জন্য শর্তাধীন হেডারগুলি (যেমন If-Match) চায়। সম্পদটি পুনরুদ্ধার করুন, এর ETag ক্যাপচার করুন এবং If-Match এর সাথে পুনরায় পাঠান।

ধীর করুন। প্রতিক্রিয়ায় একটি Retry-After হেডার অন্তর্ভুক্ত থাকা উচিত যা নির্দেশ করে কখন আবার চেষ্টা করতে হবে। অনুরোধ কোটা সহ API গুলির সাথে সাধারণ।

হয় একটি হেডার বা মোট হেডারের আকার সীমা অতিক্রম করে — সবচেয়ে প্রায়শই অত্যধিক আকারের কুকি দ্বারা সৃষ্ট। কুকিগুলি সাফ করুন বা আপনার অ্যাপ্লিকেশন যা সংরক্ষণ করে তা হ্রাস করুন।

সম্পদটি আইনি কারণে ব্লক করা হয়েছে — সেন্সরশিপ, আদেশ, বা আঞ্চলিক নিয়ম। সংখ্যাটি উপন্যাস ফারেনহাইট 451 এর একটি ইঙ্গিত।

সার্ভার-পক্ষীয় ত্রুটিগুলির জন্য একটি সাধারণ ধরে রাখুন। প্রকৃত কারণের জন্য সার্ভার লগ চেক করুন: অপরিচালিত ব্যতিক্রম, ডাটাবেস ত্রুটি, ইত্যাদি।

উদাহরণস্বরূপ, সার্ভার HTTP পদ্ধতি স্বীকার করে না। অনুশীলনে বিরল — আপনি আরও প্রায়শই 405 দেখতে পাবেন।

মাইক্রোসার্ভিস আর্কিটেকচারে সাধারণ। আপনার লোড ব্যালেন্সার বা রিভার্স প্রক্সি ব্যাকএন্ড সার্ভিস থেকে একটি ত্রুটিপূর্ণ প্রতিক্রিয়া পেয়েছে।

হয় রক্ষণাবেক্ষণের জন্য বন্ধ বা অতিরিক্ত লোড। প্রতিক্রিয়ায় একটি Retry-After হেডার অন্তর্ভুক্ত থাকা উচিত। প্রায়শই স্থাপনার সময় ফেরত করা হয়।

ব্যাকএন্ড সেবা যথেষ্ট দ্রুত প্রতিক্রিয়া জানায়নি। আপস্ট্রিম সেবা স্বাস্থ্য এবং টাইমআউট কনফিগারেশন চেক করুন।

অনুরোধের প্রধান HTTP সংস্করণ সার্ভার দ্বারা সমর্থিত নয়। আধুনিক ক্লায়েন্টগুলির সাথে প্রায় কখনও দেখা যায় না।

স্বচ্ছ বিষয়বস্তু আলোচনা একটি লুপে শেষ হয়েছে: নির্বাচিত বৈকল্পিক নিজেই আলোচনার জন্য কনফিগার করা হয়েছে। একটি সার্ভার কনফিগারেশন ত্রুটি নির্দেশ করে।

WebDAV মূল এ নির্দিষ্ট কিন্তু কখনও কখনও সাধারণ সার্ভার দ্বারা ব্যবহৃত হয়। মানে সার্ভার স্টোরেজ সীমাবদ্ধতার কারণে অনুরোধ সংরক্ষণ করতে পারে না।

WebDAV: একটি Depth: infinity অনুরোধ প্রক্রিয়াকরণ একটি লুপ প্রবেশ করেছে (যেমন বৃত্তাকার বাঁধাই)। অপারেশন বন্ধ করা হয়েছিল।

অপ্রচলিত HTTP এক্সটেনশন ফ্রেমওয়ার্ক থেকে: সার্ভারের অনুরোধ পূরণ করার আগে আরও তথ্য প্রয়োজন। আধুনিক ওয়েবে কার্যকরভাবে অব্যবহৃত।

ক্যাপটিভ পোর্টাল (হোটেল/বিমানবন্দর WiFi) দ্বারা ব্যবহৃত হয় ব্যবহারকারীকে বাহ্যিক সাইটগুলি অ্যাক্সেস করার আগে নেটওয়ার্কে লগ ইন করতে হবে তা নির্দেশ করতে।