| HTTP স্টেটাস কোড | স্ট্যাটাস কোডের অর্থ |
|---|
| 100 | ক্লায়েন্ট সাইড প্রয়োজনীয়তা অব্যাহত রেকোর্ড পাঠাতে চলে। এই অস্থায়ী প্রতিক্রিয়াটি ক্লায়েন্ট সাইডকে জানাতে ব্যবহৃত হয় যে তার কিছু রেকোর্ডকে সার্ভার গ্রহণ করা হয়েছে এবং তা প্রত্যাখ্যান করা হয়নি। ক্লায়েন্ট সাইডকে বাকির রেকোর্ডকে পাঠাতে হবে, বা যদি রেকোর্ডটি সমাপ্ত হয়েছে তবে প্রতিক্রিয়াটি অবহেলা করতে হবে। রেকোর্ডটি সমাপ্ত হওয়ার পর, সার্ভারকে ক্লায়েন্ট সাইডকে শেষ প্রতিক্রিয়া পাঠাতে হবে。 |
| 101 | সার্ভার ক্লায়েন্টের অনুরোধকে বুঝেছে এবং উন্নতিকরণ হেডারের মাধ্যমে ক্লায়েন্টকে একটি ভিন্ন প্রোটোকল ব্যবহার করে অনুরোধটি সম্পূর্ণ করার জন্য অবহিত করবে। প্রতিক্রিয়ার শেষ খালি লাইন পাঠানোর পর, সার্ভার উন্নতিকরণ হেডারে নির্দিষ্ট প্রোটোকলগুলিতে স্বচালিত হবে। নতুন প্রোটোকলে স্বচালিত হওয়ার ক্ষেত্রে এমন উপায়গুলি কেবলমাত্র গ্রহণ করা উচিত। উদাহরণস্বরূপ, নতুন HTTP সংস্করণে স্বচালিত হওয়ার সুবিধা পুরানো সংস্করণের উপর থাকে, বা স্বচালিত-সময় এবং সিনক্রোনাস প্রোটোকল যেমন এই সময়কালে এবং সিনক্রোনাস প্রোটোকল যেমন এই সময়কালে |
| 102 | WebDAV (RFC) 2518) ইঙ্গিত করে যে, প্রক্রিয়া অব্যাহত থাকবে |
| 200. | অনুরোধ সফল হয়েছে, এবং কোনো ইচ্ছিত রেসপন্স হেডার বা ডেটা বডি রেসপন্সের সাথে ফিরিয়ে দেওয়া হয়。 |
| 201 | অনুরোধ সফল হয়েছে, এবং অনুরোধের প্রয়োজনীয়তা অনুযায়ী একটি নতুন রিসোর্স তৈরি হয়েছে, এবং তার URI-টি 'লোকেশন' হেডারের সাথে ফিরিয়ে দেওয়া হয়। যদি প্রয়োজনীয় রিসোর্সটি সময়ের মধ্যে তৈরি করা যায় না, '202 ফিরিয়ে দেওয়া উচিত |
| 202 | সার্ভার অনুরোধ গ্রহণ করেছে, কিন্তু এটা এখনও প্রক্রিয়াকরণ করা হয়নি। যেমন এটা প্রত্যাখ্যান করা হতে পারে, অনুরোধটি অবশেষে কার্যকর হতে পারে কিংবা না। অসিনক্রোনাস অপারেশনের ক্ষেত্রে, এই স্ট্যাটাস কোড পাঠানোই সবচেয়ে সহজ পদ্ধতি। 'গ্রহণকৃত' নামক স্ট্যাটাস কোড ফিরিয়ে দেওয়ার উদ্দেশ্য 202 স্ট্যাটাস কোড প্রতিক্রিয়াটিকে সার্ভারকে অন্য প্রক্রিয়াগুলির (যেমন ব্যাচ) অনুরোধ গ্রহণ করতে দেয়-একবার দিনে করা হয় এমন একটি প্রক্রিয়া যা সার্ভারের সাথে ক্লায়েন্টকে সাথে রাখাতে হয় না পর্যন্ত ব্যাচ অপারেশন সম্পূর্ণ হয় না। প্রক্রিয়াকরণের জন্য একটি অনুরোধ গ্রহণ এবং ফিরিয়ে দেওয়ার প্রতিক্রিয়ায় 202 স্ট্যাটাস কোড, ফিরিয়ে দেওয়া এনটিটির মধ্যে প্রক্রিয়ার বর্তমান অবস্থা নির্দেশকারী তথ্য থাকবে, এবং প্রক্রিয়ার অবস্থা নিরীক্ষক বা অনুমান পদ্ধতির পুলটি এবং তারপর ব্যবহারকারীকে প্রক্রিয়াটি সম্পূর্ণ হয়েছে কিনা বলে অনুমান করতে পারবে। |
| 203 | সার্ভারটি সফলভাবে রিকোর্ড প্রক্রিয়াকরণ করেছে, কিন্তু ফিরিয়ে দেওয়া এনটিটি হেডার মেটা তথ্যটি মূল সার্ভারে বৈধ নিশ্চিততার বিনিময় নয়, বরং স্থানীয় বা তৃতীয়-পার্টি কপি। বর্তমান তথ্যটি প্রথম সংস্করণের উপ-সংজ্ঞা বা উপ-সংজ্ঞা হতে পারে। উদাহরণস্বরূপ, সম্বল ধারণকারী মেটা সংকেতকারী মূল সার্ভারকে মেটা সুপার জানাতে পারে। এই স্ট্যাটাস কোডটি প্রয়োজন নয়, এটি মূলত তথ্যটি ফিরিয়ে দিতে সঠিক হয়, যদি প্রতিক্রিয়াটি ফিরিয়ে দিতে হয় 200 ওক এই স্ট্যাটাস কোডের বিশেষে |
| 204 | সার্ভারটি সফলভাবে রিকোর্ড প্রক্রিয়াকরণ করেছে, কিন্তু কোনও ভৌত কনটেন্ট ফিরিয়ে দিতে প্রয়োজন নেই, এবং তাৎক্ষণিকভাবে মেটা তথ্য অপশিষ্ট ফিরিয়ে দিতে ইচ্ছুক। প্রতিক্রিয়াটি একটি এনটিটি হেডারের রূপে থাকতে পারে, নতুন বা সংশোধিত মেটা তথ্য ফিরিয়ে দিতে। যদি হেডার তথ্যটি উপস্থিত হয়, তবে তা অনুরোধক ভাবের সাথে মানানসপ্রণ্ন হতে হবে। যদি ক্লায়েন্টটি একটি ব্রাউজার হয়, তবে ব্যবহারকারীর ব্রাউজারটি রিকোর্ড করা পৃষ্ঠাটিকে কোনও পরিবর্তন ছাড়াই রাখতে হবে, যদি নতুন বা সংশোধিত মেটা তথ্যটি ব্যবহারকারীর ব্রাউজারের সক্রিয় দৃশ্যের ডকুমেন্টে অনুযায়ী প্রয়োগ করা হয়। যেহেতু 204 প্রতিক্রিয়াটি কোনও মেসেজ বডি সমূহকে যোগ করা না হতে পারে, এটি হেডারের পরের প্রথম শুধুমাত্র সূচকটির সাথে শেষ হয়。 |
| 205 | সার্ভারটি সফলভাবে রিকোর্ড প্রক্রিয়াকরণ করেছে এবং কিছুই ফিরিয়েনি। কিন্তু অলপ ভাবে 204 প্রতিক্রিয়া, এই স্ট্যাটাস কোডের প্রতিক্রিয়াটি অনুরোধককে ডকুমেন্ট ভিউ রিসেট করতে হয়। এই প্রতিক্রিয়াটি মূলত ব্যবহৃত হয় যখন ব্যবহারকারীর ইনপুট গ্রহণ করা হয়, তারপর ফর্মটি তাৎক্ষণিকভাবে রিসেট করা হয় যাতে ব্যবহারকারী সহজেই আরেকটি ইনপুট শুরু করতে পারে। যেমন আমরা 204 রিসপন্স, এই রিসপন্সও কোনও মেসেজ বডি সম্মিলিত করা না হবে এবং হেডারের পরের প্রথম খালি লাইনের সাথে শেষ হবে |
| 206 | সার্ভার সফলভাবে GET রিকোর্ডটির একটি অংশ প্রক্রিয়াকরণ করেছে।ফ্ল্যাশগেট বা ক্ষুদ্রকায়নী এই ধরণের রিসপন্স ব্যবহার করে ব্রেকপয়েন্ট কনটিনিউয়েশন বা একটি বড় ডকুমেন্টকে বহুটি ডাউনলোড সেগমেন্টে বিভক্ত করে সময়ের মধ্যেই ডাউনলোড করা হয়-রেঞ্জ হয়, তবে রিসপন্সের মধ্যে নিম্নলিখিত হেডার ফিল্ডগুলি থাকতে হবে-রেঞ্জ দ্বারা এই রিসপন্সের মধ্যে কনটেন্টের রেঞ্জ ইনডিকেট করা; যদি এটি একটি মাল্টি-সেগমেন্ট ডাউনলোড করা সম্ভব, কনটেন্ট-মাল্টিপার্ট/বাইট রেঞ্জ থাকে, তবে প্রত্যেক মাল্টিপার্ট সেগমেন্টকে একটি কনটেন্ট-রেঞ্জ ফিল্ডকে এই সেগমেন্টের কনটেন্ট রেঞ্জ ইনডিকেট করা।যদি রিসপন্সের মধ্যে কনটেন্ট-লেন্গথ, তবে এর মান কনটেন্ট রেঞ্জের মধ্যে এক্সটার্নাল বাইটসমূহের সংখ্যা মানের সাথে একই হতে হবে/বা Content-Location, যদি একই অনুরোধটি একই প্রতিক্রিয়া পাওয়ার জন্য উচিত হতে পারে 200 প্রতিক্রিয়া। Expires, Cache-কন্ট্রোল, এবং/বা Vary কেন্দ্রীকৃত হয়, তবে এর মান পূর্ববর্তী রিসপন্সের মান থেকে ভিন্ন হতে পারে-রেঞ্জ স্ট্রংক্স ক্যাশ ভ্যালিডেশন, তাহলে এই রিসপন্সের মধ্যে অন্যান্য এনটিটি হেডারগুলি সম্মিলিত করা উচিত না; যদি এই রিসপন্সের মানকের মানকের মতো হতে পারে, তবে-রেঞ্জ হ্যাক্সি ক্যাশ ভ্যালিডেশন, তাহলে এই রিসপন্সের মধ্যে অন্যান্য এনটিটি হেডারগুলি সম্মিলিত করা উচিত না; এটি ক্যাশেড এনটিটির কনটেন্ট এবং অপদান এনটিটি হেডার তথ্যগুলির মধ্যে অসঙ্গতিকে বাধা দেয় 200 রিসপন্সের কনটেন্ট-রেঞ্জ এবং কনটেন্ট মডিফাইড হেডারগুলির মান একই না হলে, ক্লায়েন্ট সাইড ক্যাশের সাথে কনটেন্টকে মিশ্রিত করা না হবে 206 রিসপন্সের কোনও পূর্ববর্তী ক্যাশেড কনটেন্টের সাথে-রেঞ্জ হেডার পূর্ববর্তী ক্যাশেড কনটেন্টকে ক্যাশিং করা না হবে 206 রিসপন্স |
| 207 | ওয়েবডেভ (RFC)-এর দ্বারা সম্প্রসারিত একটি স্ট্যাটাস কোড 2518) পরবর্তী সংবাদের বড়ার জন্য একটি XML সংবাদ হবে, এবং পূর্ববর্তী সাব-রিকোর্ডের সংখ্যা অনুযায়ী একটি শৃঙ্খলা স্বতন্ত্র প্রতিক্রিয়া কোডগুলি ধারণ করতে পারে।-রিকোর্ড করে |
| 300 | রিকোর্ড করে, যা পূর্ববর্তী সাব-রিকোর্ডের সংখ্যা অনুযায়ী একটি শৃঙ্খলা স্বতন্ত্র প্রতিক্রিয়া কোডগুলি ধারণ করতে পারে।-নির্দিষ্ট ফরম্যাট দ্বারা নির্ধারিত হয়।অনুরোধ করা সম্বলটি একটি প্রতিক্রিয়ার বিভিন্ন ফিডব্যাক বিকল্প ধারণ করে, যার প্রত্যেকটিতে নিজস্ব বিশেষ ঠিকানা এবং ব্রাউজার-নিয়ন্ত্রিত আলোচনা তথ্য।ব্যবহারকারী বা ব্রাউজারটি পুনর্নির্দেশনার জন্য একটি পছন্দ করা ঠিকানা বেছে নিতে পারে।যদি এটি একটি HEAD রিকোর্ড না হয়, তাহলে প্রতিক্রিয়াটি একটি এন্টিটি ধারণ করবে যা সম্বল বৈশিষ্ট্য এবং ঠিকানার তালিকা ধারণ করবে, যা ব্যবহারকারী বা ব্রাউজারটি সবচেয়ে উপযুক্ত পুনর্নির্দেশনার ঠিকানা বেছে নিতে পারে।এই এন্টিটির ফরম্যাটটি Content-এর 2616 টাইপ।ব্রাউজারটি প্রতিক্রিয়ার ফরম্যাট এবং ব্রাউজারের নিজস্ব ক্ষমতা অনুযায়ী সবচেয়ে উপযুক্ত পছন্দ করতে স্বয়ংক্রিয়ভাবে করতে পারে।সবাইকে নিয়ে নিয়ে RFC-এর |
| 301 | অনুরোধ করা সম্বল স্থায়ীভাবে একটি নতুন স্থানে স্থানান্তরিত হয়েছে, এবং এই সম্বলের ভবিষ্যত উল্লেখের জন্য এই প্রতিক্রিয়া দ্বারা ফিরিয়ে দেওয়া একাধিক URI-কে ব্যবহার করা উচিত।যদি সম্ভব, লিঙ্ক সম্পাদনা ক্ষমতা সহ ক্লায়েন্টটি স্বয়ংক্রিয়ভাবে অনুরোধ করা ঠিকানা সার্ভার থেকে ফিরিয়ে দেওয়া ঠিকানায় পরিবর্তন করা উচিত।যদি অন্যথায় নির্দিষ্ট না হয়, এই প্রতিক্রিয়াটি সংরক্ষণযোগ্যও থাকে।নতুন স্থায়ী URI-টি প্রতিক্রিয়ার Location ফিল্ডে ফিরিয়ে দেওয়া উচিত।যদি এটি একটি HEAD রিকোর্ড, তাহলে প্রতিক্রিয়ার এন্টিটি নতুন URI-কে একটি হাইপারলিঙ্ক এবং স্মৃতিস্তর বর্ণনা ধারণ করবে।যদি এটি GET বা HEAD রিকোর্ড না হয়, তাহলে ব্রাউজারটি ব্যবহারকারীর নিশ্চয়করণের পর শুধুমাত্র স্বয়ংক্রিয়ভাবে পুনর্নির্দেশনা করতে পারবে, কারণ অনুরোধের শর্তগুলি পরিবর্তিত হতে পারে।পরীক্ষা: কিছু ব্রাউজারের জন্য HTTP-এর নির্দেশিকা সংজ্ঞা করে না যে, এই স্বয়ংক্রিয় পছন্দ কীভাবে করা উচিত হবে।যদি সার্ভারটি নিজেই একটি পছন্দ করা প্রতিক্রিয়া বাছাই করেছে, তাহলে প্রতিক্রিয়ার URI-টি Location-এ নির্দিষ্ট করা উচিত; ব্রাউজারগুলি এই Location মানকে স্বয়ংক্রিয়ভাবে পুনর্নির্দেশনার ঠিকানা হিসাবে ব্যবহার করতে পারে।এছাড়া, যদি অন্যথায় নির্দিষ্ট না হয়, প্রতিক্রিয়াটি সংরক্ষণযোগ্যও থাকে।/1.0 protocol, when they send a POST request and get a 301 response, the subsequent redirect request will be GET. |
| 302 | The requested resource is now temporarily responding to the request from a different URI. Since such redirects are temporary, the client side should continue to send future requests to the original address. This response is cacheable only if specified in Cache-Control or Expires. The new temporary URI should be returned in the Location field of the response. Unless this is a HEAD request, the response entity should contain a hyperlinke to the new URI and a brief description. If this is not a GET or HEAD request, the browser prohibits automatic redirection unless confirmed by the user, as the conditions of the request may change as a result. Note: Although the RFC 1945 and RFC 2068 specifications do not allow the client side to change the method of the request when redirecting, many existing browsers treat the 302 response as a 303 response and use GET to access the URI specified in the Location, ignoring the original request method. Status codes 303 and 307 were added to clarify what the server expects from the client side. |
| 303 | The response to the current request can be found on another URI, and the client side should GET access to that resource. This method exists primarily to allow script-activated POST request output to be redirected to a new resource. This new URI is not a substitute reference to the original resource. Also, 303 প্রতিক্রিয়াগুলি ক্যাশেড করা নিষিদ্ধ, স্বাভাবিকভাবে, একটি দ্বিতীয় অনুরোধ (রিডিরেক্ট) ক্যাশেড করা যেতে পারে। নতুন URI-টি প্রতিক্রিয়ার Location ফিল্ডে ফিরিয়ে দিতে হবে। যদি এটি HEAD অনুরোধ না হলে, প্রতিক্রিয়ার এনটিটিতে নতুন URI-কে হাইপারলিঙ্ক এবং স্মৃতিকৃত বর্ণনা থাকতে হবে। নোট: HTTP পূর্ববর্তী অনেক ব্রাউজার/1.1 যারা বুঝে না 303 যদি আপনি এই ব্রাউজারগুলির সঙ্গে সম্পর্ক বিবেচনা করতে হয়, তবে 302 স্ট্যাটাস কোড যথেষ্ট হবে, কারণ অধিকাংশ ব্রাউজারগুলি স্ট্যাটাস কোডকে সঠিকভাবে হস্তক্ষেপ করে 302 প্রতিক্রিয়াগুলি সঠিকভাবে ক্লায়েন্ট পক্ষটির দ্বারা হস্তক্ষেপ নিয়ে একইভাবে প্রক্রিয়াকরণ করা হবে 303 প্রতিক্রিয়াগুলি |
| 304 | যদি ক্লায়েন্ট পক্ষটি শর্তমূলক GET অনুরোধ পাঠায় এবং অনুরোধটি অনুমোদিত হয়, এবং ডকুমেন্টের কনটেন্ট পরিবর্তিত হয়নি (গত সফর থেকে বা অনুরোধের শর্ত অনুযায়ী), তবে সার্ভারটি এই স্ট্যাটাস কোড প্রতিক্রিয়া দিবে 304 প্রতিক্রিয়াগুলি মুম্বলীভাবে কনটেন্ট নিহিত করবে, তাই হেডারের পরবর্তীতে প্রথম শুধু স্থান সহ সমাপ্ত হবে। প্রতিক্রিয়াটিতে নিম্নলিখিত হেডার তথ্য থাকতে হবে: Date, যদি এই সার্ভারটিতে ঘড়ি না থাকে
যদি ঘড়ি থাকা না থাকা সার্ভারটিও এই নিয়মগুলি মেনে চলে, তবে প্রক্সি সার্ভার এবং ক্লায়েন্ট পক্ষকে নিজেদের দ্বারা প্রাপ্ত প্রতিক্রিয়া হেডারের ডেট ফিল্ড যোগ করতে পারে (RFC অনুযায়ী নির্দিষ্ট হয়েছে) 2068), এবং ক্যাশিং মেকানিজম সুবাহারীভাবে কাজ করবে। ETag এবং/বা Content-Location, যদি একই অনুরোধটি একই প্রতিক্রিয়া পাওয়ার জন্য উচিত হতে পারে 200 প্রতিক্রিয়া। Expires, Cache-কন্ট্রোল, এবং/বা Vary, যদি তার মান আগের প্রতিক্রিয়াগুলির তথ্যের মান থেকে ভিন্ন হতে পারে
যদি এই প্রতিক্রিয়া অনুরোধটি শক্ত ক্যাশ নিশ্চয়ন ব্যবহার করে, তবে এই প্রতিক্রিয়াটিতে অন্যান্য এনটিটি হেডারগুলি সম্মিলিত হবে না; অন্যথায় (উদাহরণস্বরূপ, একটি শর্তমূলক GET অনুরোধ দুর্বল ক্যাশ নিশ্চয়ন ব্যবহার করে), এই প্রতিক্রিয়াটিতে অন্যান্য এনটিটি হেডারগুলি সম্মিলিত করা নিষিদ্ধ; এর মাধ্যমে ক্যাশেড এনটিটি কনটেন্ট এবং নতুনভাবে এনটিটি হেডার তথ্যের মধ্যে অসমতা এড়ানো হয়। যদি 304 প্রতিক্রিয়া নিশ্চিত করে যে একটি পদার্থকে এখনও ক্যাশেতে নেই, তবে ক্যাশিং সিস্টেমকে এই প্রতিক্রিয়াকে অণচলানো হবে এবং নিষিদ্ধ নয়াদিক প্রবেশ করার জন্য পুনরাবৃত্ত প্রবেশ করতে হবে।
যদি একটি 304 প্রতিক্রিয়া পাওয়া গেলে, যার মাধ্যমে ক্যাশকে অদূর্ঘটি পুনর্নবীকরণ করা হয়, তবে ক্যাশিং সিস্টেমকে সমস্ত ক্ষেত্রগুলির মানকে পরিবর্তন করার জন্য সমস্ত ক্ষেত্রগুলির মানকে পরিবর্তন করা হবে。 |
| 305 | রিকোর্ড সম্বন্ধীয় রিসোর্সকে স্পেসিফাইক প্রক্সি-এর মাধ্যমে পরিবেশিত হতে হবে। স্পেসিফাইক প্রক্সির URI-কে স্থানাঙ্ক ফিল্ডে দেওয়া হয়। প্রাপককে এই প্রক্সি-এর মাধ্যমে প্রতিযোগী রিসোর্সকে প্রবেশ করার জন্য পৃথক প্রবেশ করার জন্য পৃথক প্রবেশ করতে হবে। শুধুমাত্র মূল সার্ভারই একটি 305 প্রতিক্রিয়া। নোট: স্পষ্ট 305 RFC-এর প্রতিক্রিয়া 2068 একটি একক রিকোর্ডকে পুনর্নির্দেশিত করার জন্য, এটি শুধুমাত্র মূল সার্ভার দ্বারা স্থাপন করা যায়। এই নিয়ন্ত্রণগুলিকে অণচলানোর ফলে গুরুতর নিরাপত্তা পরিণাম হতে পারে。 |
| 306 | সংজ্ঞার সর্বশেষ সংস্করণে 306 স্ট্যাটাস কোড এখন ব্যবহার করা হয় না。 |
| 307 | অনুরূপ সম্বন্ধে অনুরূপ রিসোর্স এখন অন্য উপাদানের URI-এর থেকে অনুরূপ প্রতিক্রিয়া দিচ্ছে। এই পুনর্নির্দেশনা অস্থায়ী, তাই ক্লায়েন্ট পক্ষকে ভবিষ্যতের রিকোর্ড প্রবেশ করতে মূল ঠিকানায় চলতে হবে। এই প্রতিক্রিয়াটিকে মাত্র Cache-এর উল্লেখ করা হলেই ক্যাশ করা যাবে。-কন্ট্রোল বা Expires। নতুন অস্থায়ী URI-কে প্রতিক্রিয়ার Location ফিল্ডে ফিরিয়ে দিতে হবে। যদি এটি HEAD রিকোর্ড না হোক, প্রতিক্রিয়ার নিম্নস্থ পদার্থকে নতুন URI-এর লিঙ্ক এবং স্বল্প বিবরণ নিয়ে থাকতে হবে। কারণ কিছু ব্রাউজারকে তা পরিচিত নয় 307 রিস্পঞ্জ, উপরোক্ত তথ্যকে যোগ করতে হবে তাকে ব্যবহারকারীকে বোঝা যায় এবং নতুন URI-এর প্রবেশ করার জন্য অনুরোধ করা যায়。
যদি এটি GET বা HEAD রিকোর্ড না হোক, তবে ব্রাউজার অটোমেটিক রেডিরেকশনকে নিষিদ্ধ করে, যতক্ষণ ব্যবহারকারীর নিশ্চয়তা পাওয়া যায় না, কারণ রিকোর্ডের শর্তগুলি এই ফলে পরিবর্তিত হতে পারে。 |
| 400 | 1অর্থবাহিত ভুল এবং বর্তমান অনুরোধটি সার্ভারের দ্বারা বুঝা যায় না। পরিবর্তন করা না হলে, ক্লায়েন্ট সাইডটি অনুরোধটি পুনরায় প্রস্তুত করতে না হবে। 2অনুরোধ প্রাপ্ত প্রমাণপত্রগুলি ভুল হয়েছে。 |
| 401 | বর্তমান অনুরোধটির জন্য ব্যবহারকারী প্রমাণপত্র প্রয়োজন। প্রতিক্রিয়াটির মধ্যে একটি WWW-অনুরোধকৃত রিসোর্সের জন্য অথেনটিকেশন হেডারটি ব্যবহার করে ব্যবহারকারীকে তথ্য চেয়ে নেয়। ক্লায়েন্ট সাইডটি উপযুক্ত অথরাইজেশন হেডার তথ্যসহ অনুরোধটি পুনরায় প্রস্তুত করতে পারে। যদি বর্তমান অনুরোধটির মধ্যে ইউজার অথরাইজেশন সার্টিফিকেটগুলি পরিচিত থাকে 401 প্রতিক্রিয়াটি সার্ভারটি সেইসব সার্টিফিকেটগুলিকে বাতিল করেছে। যদি 401 প্রতিক্রিয়াটি পূর্ববর্তী প্রতিক্রিয়াটির সমপর্যায় প্রমাণপত্র কোডটি ধারণ করে, এবং ব্রাউজারটি একবারও প্রমাণপত্র চেষ্টা করেছে, তবে ব্রাউজারটি প্রতিক্রিয়াটির মধ্যে থাকা এন্টিটির তথ্যটি ব্যবহারকারীকে দেখাতে হবে, কারণ এই এন্টিটির তথ্যটি প্রাসঙ্গিক ডিগ্রামটি ধারণ করতে পারে। দেখুন RFC 2617. |
| 402 | এই স্ট্যাটাস কোডটি ভবিষ্যতের সম্ভাব্য প্রয়োজনীয়তার জন্য সংরক্ষিত রয়েছে。 |
| 403 | সার্ভারটি অনুরোধটি বুঝেছে, কিন্তু তা করতে সম্মত হয়নি। একটি 401 প্রতিক্রিয়াটি, প্রমাণপত্র ব্যবহার করা হয় না, এবং অনুরোধটি পুনরায় করা হবে না। যদি এটি একটি HEAD অনুরোধ না হয়, এবং সার্ভারটি অনুরোধটি কেন করা যায়নি তা ব্যক্ত করতে চায়, তবে বাতিলকরণের কারণটি এন্টিটিতে বর্ণনা করা হবে। সার্ভারটি কারণটি ব্যক্ত করতে পারবে 404 প্রতিক্রিয়াটি ক্লায়েন্ট সাইডের কোনো তথ্য পাওয়ার জন্য না হতে চায়。 |
| 404 | অনুরোধটি ব্যর্থ হয়েছে, এবং দুশুক্ত রিসোর্সটি সার্ভারে পাওয়া যায়নি। ব্যবহারকারীকে কোনো সময়কালীন বা স্থায়ী অবস্থা কী হয়েছে তা জানানোর কোনো তথ্য নেই। যদি সার্ভার এই পরিস্থিতির কথা জানে, তবে 410 স্ট্যাটাস কোডটি পুরনো রিসোর্সটিকে বুঝাতে ব্যবহার করা হয় যে এটি কোনো ইন্টারনাল কনফিগারেশন মেকানিজমের কারণে স্থায়ীভাবে নাও উপলব্ধ এবং যেকোনো অন্য অস্থায়ী অস্থানে জুম করা যাবে না。 404 সার্ভার কারণটি প্রকাশ করতে চায় না বা কোনো অন্য উপযুক্ত প্রতিক্রিয়া উপলব্ধ না থাকলে, স্ট্যাটাস কোড ব্যবহার করা হয়。 |
| 405 | অনুরোধ লাইনে নির্দিষ্ট অনুরোধ পদ্ধতি প্রয়োজনীয় সম্পদকে অনুরোধ করার জন্য ব্যবহার করা যায় না। প্রতিক্রিয়াটি সর্বদা একটি অনুমতি হেডার পুনরায় প্রদান করবে যা বর্তমান সম্পদটির দ্বারা গ্রহণযোগ্য অনুরোধ পদ্ধতিগুলির তালিকা নির্দেশ করে। যেহেতু PUT এবং DELETE পদ্ধতিগুলি সার্ভারের সম্পদে লেখা করে, অধিকাংশ ওয়েব সার্ভারটি ডিফল্টে এই অনুরোধ পদ্ধতিকে সমর্থন করে না বা অনুমতি দেয় না, এবং পুনরায় 405 এই ধরণের অনুরোধগুলির জন্য এর্রর করা হবে。 |
| 406 | অনুরোধকৃত সম্পদের সামগ্রীর বৈশিষ্ট্যগুলি অনুরোধ হেডারের শর্তগুলির সাথে মানানসপ্রণীত নয়, তাই প্রতিক্রিয়া এনসিটি তৈরি করা যায় না। এটি HEAD অনুরোধ না হলে, প্রতিক্রিয়াটি ব্যবহারকারীকে বা ব্রাউজারকে সর্বাধিক উপযুক্ত এনসিটি বৈশিষ্ট্য এবং ঠিকানা তালিকা বাছাই করতে অনুমতি দেওয়া এনসিটি পুনরায় প্রদান করবে। এনসিটির ফরম্যাটটি কন্টেন্ট-টাইপ হেডার। ব্রাউজারটি ফরম্যাট এবং নিজস্ব ক্ষমতার ভিত্তিতে সর্বোত্তম বাছাই করতে পারে। কিন্তু এই ধরণের স্বয়ংক্রিয় বাছাই করার জন্য কোনও নির্দিষ্ট নীতি নির্দিষ্ট করা হয়নি。 |
| 407 | অনুরূপ 401 প্রতিক্রিয়া, যদিও ক্লায়েন্ট পক্ষটি প্রক্সি সার্ভারে প্রমাণপত্র করতে হবে। প্রক্সি সার্ভারটি একটি প্রক্সি-প্রমাণপত্র করুন অথেনটিকেশনের জন্য। ক্লায়েন্ট পক্ষটি একটি প্রক্সি-প্রমাণপত্র হেডার অথেনটিকেশনের জন্য। দেখুন RFC 2617. |
| 408 | অনুরোধটির সময়সীমা শেষ হয়েছে। ক্লায়েন্ট পক্ষটি সার্ভারটি অপেক্ষা করার সময়ের মধ্যে অনুরোধটি পাঠানো করতে পারেনি। ক্লায়েন্ট পক্ষটি কোনও পরিবর্তন ছাড়াই কোনও সময় অনুরোধটি পুনরায় প্রক্ষেপণ করতে পারে。 |
| 409 | প্রয়োজনীয় সম্পদের বর্তমান অবস্থার সাথে টিকেউঠলের কারণে অনুরোধটি সম্পন্ন করা যায় না। এই কোডটি শুধুমাত্র ব্যবহার করা যেতে পারে যদি ব্যবহারকারীকে টিকেউঠল সমাধান করতে পারবে এবং একটি নতুন অনুরোধ পুনরায় প্রক্ষেপণ করবে। প্রতিক্রিয়াটিতে ব্যবহারকারীকে টিকেউঠলের উৎস খুঁজে বের করার জন্য পর্যাপ্ত তথ্য থাকা উচিত। টিকেউঠলরূপরেখা সাধারণত PUT অনুরোধের প্রক্রিয়ায় ঘটে। উদাহরণ হিসেবে, একটি-নিয়ন্ত্রিত পরিবেশ, যদি একটি পুটের সাথে যুক্ত হওয়া সংস্করণ তথ্য-রিকোর্ড পরিবর্তন জানানোর জন্য সম্পূর্ণ প্রয়োগ জানানোর জন্য, এই রিকোর্ডটির পূর্ববর্তী (তৃতীয়-পক্ষের) রিকোর্ড জানানোর জন্য, সার্ভার একটি 409 রিকোর্ড সম্পূর্ণ করতে পারছে না এই ত্রুটিকে ব্যবহারকারীকে জানানোর জন্য এই ত্রুটি
এই সময়, প্রতিক্রিয়ার সংস্থানটি দুই সংঘাতিত সংস্করণের মধ্যে পার্থক্য তুলে ধরতে হবে, তারপর ব্যবহারকারী মিশ্রিত সংস্করণটি পুনরায় জমা দিতে পারবে。 |
| 410 | রিকোর্ড প্রতিষ্ঠানটি আর নিষ্ক্রিয়, এবং কোনও পূর্ববর্তী প্রয়োগ এই রিকোর্ডটির সাথে কোনও পূর্ববর্তী প্রয়োগ নেই। এই অবস্থাটি স্থায়ী হিসাবে গ্রহণ করা উচিত। যদি সম্ভব, ক্লায়েন্ট পক্ষের লিঙ্ক সম্পাদনা ক্ষমতা থাকে, তবে এই ঠিকানার সমস্ত উল্লেখকে ব্যবহারকারীর অনুমতিতে সরিয়ে দিতে হবে। যদি সার্ভার এই অবস্থাটি স্থায়ী হলে জানতে পারে না বা নিশ্চিত করতে পারে না, তবে 404 স্ট্যাটাস কোড ব্যবহার করা উচিত। বর্তমানে বিনা উল্লেখ করা হলে, এই প্রতিক্রিয়া ক্যাশেবল হবে। এর উদ্দেশ্য 410 রিসোর্সটি আর নিষ্ক্রিয়, এবং সার্ভার মালিক এই রিসোর্সকে কোনও দূরত্ব সংযোগ করা হয়নি, এটা কি হবে তা সার্ভার মালিকের হাতেই পড়ে।
এই ধরণের ঘটনা সময়ের মধ্যে সাধারণ-সীমিত, মূল্য-যুক্ত হওয়া সার্ভিস 410 রিসোর্সটি সম্পূর্ণভাবে সার্ভার সাইটে উপলব্ধ নেই, এটা সার্ভার মালিকের হাতেই পড়ে যে, সমস্ত স্থায়ীভাবে নিষ্ক্রিয় হওয়া রিসোর্সকে ' 410 গোন এবং এই নিদর্শনটি কত সময় রাখা হবে |
| 411 | সার্ভার বিনা কনটেন্ট নির্ধারণ করে রিকোর্ড নিন্ন প্রয়োজন-লেন্থ হেডার-রিকোর্ড হেডার জোনকরে রিকোর্ড বডির দৈর্ঘ্য, ক্লায়েন্ট পক্ষ রিকোর্ড পুনরায় জমা দিতে পারে。 |
| 412 | The server failed to meet one or more of the prerequisites when verifying that they were given in the header field of the request. This status code allows the client side to set prerequisites in the requested metadata (request header field data) when fetching resources, thus preventing the request method from being applied to resources other than what it wants. |
| 413 | সার্ভারটি বর্তমান রিকেজটিকে প্রক্রিয়াজাত করতে অস্বীকার করেছে কারণ রিকেজটি যতটা এনটিটি ডাটা জমা দিয়েছে, যা সার্ভারটি প্রত্যাখ্যান করা বা হাতকরা পারে। এই ক্ষেত্রে, সার্ভারটি কান্না সংযোগটি বন্ধ করতে পারে যাতে ক্লায়েন্টকে রিকেজটি পাঠানোর জন্য চালানো না হয়। এই পরিস্থিতি অপরিণত হলে, সার্ভারটি একটি রিট্রি করা উচিত-রিসপন্স হেডারের পরে, ক্লায়েন্টকে কতটা সময় পুনরায় চেষ্টা করতে পারবে তা নির্দেশ করার জন্য |
| 414 | রিকেজটিতে অনুরোধ করা ইউআরআই সার্ভারটির উপলব্ধ করতে পারা না, তাই সার্ভারটি রিকেজটিকে পরিচালনা করতে অস্বীকার করে। এটি অপরিণত, এবং সাধারণ ক্ষেত্রগুলির মধ্যে রয়েছে: একটি ফর্ম সাবমিশন যা পোস্ট পদ্ধতিকে ব্যবহার করা উচিত হলেও গেট পদ্ধতিতে হয়েছে, যা কোয়ার্শিস স্ট্রিং (কোয়ার্শিস স্ট্রিং)কে খুব দীর্ঘ করে তোলে। রেডিরেক্ট ইউআরআই "কালো গুহা", যেমন প্রত্যেক রেডিরেক্ট পুরনো ইউআরআইকে নতুন ইউআরআইর অংশ হিসাবে ব্যবহার করে, যা পরবর্তী রেডিরেক্টগুলিতে ইউআরআইকে খুব দীর্ঘ করে তোলে। ক্লায়েন্ট সার্ভারকে কোনও সার্ভারের মধ্যে সুরক্ষা বাগ দিয়ে হামলা করছে
এই ধরণের সার্ভারটি একটি স্থির-বুফার লেন্ড কিংবা নির্দিষ্ট রিকেজটিতে পড়া বা সংক্রান্ত করার জন্য লেন্ড বুফার সাইজ1]. এমন দুর্বলতা থাকা না থাকা সার্ভারটি একটি রিটার্ন করা উচিত 414 স্ট্যাটাস কোড |
| 415 | বর্তমান রিকেজটির পদ্ধতি এবং অনুরোধ করা সম্পদের জন্য, রিকেজটিতে সার্ভারটির দ্বারা সমর্থিত একটি ফরম্যাটে এনটিটি জমা দেওয়া হয়নি, তাই রিকেজটি প্রত্যাখ্যান করা হয় |
| 416 | যদি রিকেজটিতে একটি রেঞ্জ হেডার থাকে, এবং রেঞ্জটিতে নির্দিষ্ট কোনও ডাটা রেঞ্জ বর্তমান সম্পদের সম্পর্কিত রেঞ্জের সাথে একই নয়, এবং যদি-রিকেজ হেডার রিকেজটিতে নির্দিষ্ট নয়, সার্ভারটি একটি রিটার্ন করা উচিত 416 status code. If the Range uses a byte range, then this situation means that the first byte position of all data ranges specified by the request exceeds the length of the current resource. The server should also include a Content-Range entity header along with the 416 status code to indicate the length of the current resource. This response is also prohibited from using multipart/byteranges as its Content-Type. |
| 417 | রিকোর্ডের হেডারে স্পেসিফাইক আশা করা কনটেন্টটি সার্ভার দ্বারা পূরণ করা যায় না, বা সার্ভার একটি প্রক্সি সার্ভার, যা আশা করা কনটেন্টটি আগামী নোডে পূরণ করা যায় না এই কথার প্রমাণ পায়。 |
| 421 | ইন্টারনেট প্রোটোকল অ্যাড্রেসস থেকে সার্ভারের সাথে সংযোগের সংখ্যা, যেখানে বর্তমান ক্লায়েন্ট সাইড অবস্থিত, সার্ভার দ্বারা অনুমতিকৃত মাক্সিমাম থেকে বেশি। সাধারণত, এখানকার ইন্টারনেট প্রোটোকল অ্যাড্রেসসটি সার্ভার থেকে দেখা ক্লায়েন্ট সাইড অ্যাড্রেস (যেমন ব্যবহারকারীর গেটওয়ে বা প্রক্সি সার্ভার অ্যাড্রেস) হয়। এই ক্ষেত্রে, সংযোগ সংখ্যা একাধিক ব্যবহারকারীকেও নিয়ে থাকতে পারে。 |
| 422 | ইন্টারনেট প্রোটোকল অ্যাড্রেসস থেকে সার্ভারের সাথে সংযোগের সংখ্যা, যেখানে বর্তমান ক্লায়েন্ট সাইড অবস্থিত, সার্ভার দ্বারা অনুমতিকৃত মাক্সিমাম থেকে বেশি। সাধারণত, এখানকার ইন্টারনেট প্রোটোকল অ্যাড্রেসসটি সার্ভার থেকে দেখা ক্লায়েন্ট সাইড অ্যাড্রেস (যেমন ব্যবহারকারীর গেটওয়ে বা প্রক্সি সার্ভার অ্যাড্রেস) হয়। এই ক্ষেত্রে, সংযোগ সংখ্যা একাধিক ব্যবহারকারীকেও নিয়ে থাকতে পারে。 |
| 422 | রিকোর্ডটি সঠিকভাবে ফরম্যাট করা হয়েছে, কিন্তু সেম্যান্টিক ত্রুটির কারণে প্রতিক্রিয়া দেওয়া সম্ভব নয়।(RFC 4918 WebDAV) 423 লকড বর্তমান সম্পদটি লক করা হয়েছে।(RFC 4918 WebDAV) |
| 424 | বর্তমান রিকোর্ডটি পূর্ববর্তী রিকোর্ডের ভুলের কারণে ব্যর্থ হয়, যেমন PROPPATCH।(RFC 4918 WebDAV) |
| 425 | ওয়েবডেভ অ্যাডভান্সড কলেকশনস ড্রাফটে নির্ধারিত, কিন্তু ওয়েবডেভ সিকোয়েন্টিয়াল সেট প্রোটোকল (RFC 3658). |
| 426 | ক্লায়েন্ট সাইডকে TLS এ পরিবর্তন করা উচিত/1.0. (RFC 2817) |
| 449 | মাইক্রোসফট দ্বারা সম্প্রসারিত, উপযুক্ত কাজ করার পরে রিকোর্ডগুলি পুনরায় চেষ্টা করা উচিত。 |
| 500 | সার্ভার একটি অপ্রত্যাশিত পরিস্থিতির সম্মুখীন হয়, যা তাকে রিকোর্ডটি সম্পূর্ণ করতে বাধা দেয়। সাধারণত, এই সমস্যা সার্ভারের কোড ভুল হওয়ার সময় ঘটে。 |
| 501 | সার্ভার বর্তমান রিকোর্ডের প্রয়োজনীয় একটি প্রকারকে সমর্থন করে না। যখন সার্ভার অনুরোধ করা পদ্ধতিকে পরিচিত করতে পারে না এবং কোনও সম্পদের জন্য তার অনুরোধকে সমর্থন করতে পারে না。 |
| 502 | যখন একটি গেটওয়ে বা প্রক্সি হিসাবে কাজ করা সার্ভার একটি রিকোর্ড করার চেষ্টা করে, তা একটি অপ্রাস্তুত প্রতিক্রিয়া পায় উপস্থাপক সার্ভার থেকে。 |
| 503 | সার্ভার এখনও অনুরূপ রিকোর্ড করা পারবে না, কারণ সার্ভারের অস্থায়ী রক্ষণাবেক্ষণ বা অত্যধিক বোঝাপড়ার কারণে। এই অবস্থা অস্থায়ী এবং কিছু সময় পরে পুনরায় পুনরুদ্ধার করা হবে। যদি দ্বিতীয়বার ইন্টারভেনশন সময় পূর্বাভাস করা যায়, তবে প্রতিক্রিয়াটিতে এটা অন্তর্ভুক্ত করা যেতে পারে-হেডার দ্বারা দ্বিতীয়বার ইন্টারভেনশন সময়-পরিকল্পনা না দেওয়ার পর, ক্লায়েন্ট পাশ এটা হিসাবে হয়ে নিতে হবে 500 প্রতিক্রিয়া 503 স্ট্যাটাস কোড নিশ্চিত না করে যে সার্ভার অত্যধিক বোঝাপড়ার সময় এটা ব্যবহার করবে। কিছু সার্ভার ক্লায়েন্টের সংযোগ নিষিদ্ধ করতে ইচ্ছুক |
| 504 | যখন গেটওয়েয়ার বা প্রক্সি হিসাবে কাজ করা সার্ভার একটি রিকোর্ড করার চেষ্টা করে, তখন তা উপরূত্তর সার্ভার (URI-র মাধ্যমে পরিচিত, যেমন HTTP, FTP, LDAP) বা দ্বিতীয় সার্ভার (যেমন DNS) থেকে সময়বাহ্য প্রতিক্রিয়া পায় না। নোট: কিছু প্রক্সি সার্ভার একটি 400 বা 500 DNS কোয়েরির সময়সীমা অতিক্রম হলের সময় |
| 505 | সার্ভার অনুরূপ রিকোর্ড করা হয়নি, বা অনুরূপ রিকোর্ড করতে রাজী নয়, HTTP-এর সংস্করণটির জন্য সার্ভার সমর্থন করে না। এটা বুঝায় যে সার্ভার ক্লায়েন্ট পাশের সমসমস্ত সংস্করণকে ব্যবহার করতে পারবে না বা ব্যবহার করবে না। প্রতিক্রিয়াটিতে একটি ইনস্ট্যান্স অন্তর্ভুক্ত করা হবে যা কেন সংস্করণটি সমর্থন করা হয়নি এবং সার্ভার কোন প্রোটোকলকে সমর্থন করে |
| 506 | স্বচ্ছ কনটেন্ট বিনিময় প্রোটোকল (RFC 2295), এটা সার্ভারের অভ্যন্তরীণ কনফিগারেশন ত্রুটির প্রতিনিধিত্ব করে: অনুরূপিত বিনিময় পরিবর্তনীয় সম্পদটি স্বয়ংক্রিয় কনটেন্ট বিনিময়ের জন্য কনফিগার করা হয়েছে, এবং তাই এটা বিনিময় প্রক্রিয়ায় একটি উপযুক্ত ফোকাস নয়。 |
| 507 | সার্ভার অনুরূপ রিকোর্ড করার জন্য প্রয়োজনীয় কনটেন্ট স্টোর করতে পারে না। এই অবস্থা অস্থায়ী হিসাবে মনে করা হয়। WebDAV (RFC 4918) |
| 509 | সার্ভার ব্যান্ডওয়াইড লিমিট অর্জন করেছে। এটা একটি অধিকৃত স্ট্যাটাস কোড নয়, কিন্তু এটা সামান্য ব্যবহৃত হয়。 |
| 510 | সম্পদ অর্জনের জন্য প্রয়োজনীয় পলিসি মেট না। (RFC 2774) |
