HTTP হেডার পরীক্ষক একটি URL-এর জন্য ওয়েব সার্ভারের ফেরত দেওয়া মেটাডেটা দেখায়। Screpy একটি প্রকাশ্য GET অনুরোধ করে, সমর্থিত রিডাইরেক্ট অনুসরণ করে এবং পেজের মূল অংশ ডাউনলোড না করে শেষ রেসপন্সের হেডারের নাম ও মান দেখায়। রিডাইরেক্টের সমস্যা, প্রকাশের পরে হেডারের পরিবর্তন বা অপ্রত্যাশিত ইনডেক্সিং নির্দেশনা খুঁজতে রিপোর্ট ব্যবহার করুন।
প্রথমে পাওয়া রেসপন্স পড়ুন, তারপর ওই রিসোর্সের প্রত্যাশিত রেসপন্সের সঙ্গে তুলনা করুন। পরীক্ষা সফলভাবে শেষ হলেও সার্ভারের ত্রুটি বা অনুপযুক্ত নীতি দেখা যেতে পারে। সবুজ ফলাফল নিরাপত্তা, ক্যাশের কার্যকারিতা বা সার্চে ইনডেক্স হওয়ার স্বীকৃতি নয়।
সঠিক URL ও তার রেসপন্সের ধাপ পরীক্ষা করুন
প্রাসঙ্গিক পথ ও কোয়েরিসহ একটি পূর্ণ প্রকাশ্য HTTP বা HTTPS ঠিকানা দিন। একই ডোমেইনের হোমপেজ, PDF ও পণ্যের পেজ ভিন্ন হেডার দিতে পারে। কাল্পনিক একটি পণ্যের রেসপন্স দেখতে চাইলে সাইটের মূল ঠিকানার চেয়ে https://example.com/products/blue-mug/ বেশি কার্যকর ইনপুট।
হেডারের টেবিলের আগে রেসপন্সের ধাপ পড়ুন। রিডাইরেক্টে প্রোটোকল, হোস্ট বা পথ বদলাতে পারে। টেবিলে প্রতিটি ধাপের সব হেডার নয়, শেষ রেসপন্সের হেডার থাকে। ধাপের তালিকায় শেষ রেসপন্সও থাকে, তাই দেখানো ধাপ ও রিডাইরেক্টের সংখ্যা সমান নাও হতে পারে।
শেষ URL-টি কাঙ্ক্ষিত রিসোর্স কি না নিশ্চিত করুন। লগইন পেজ, ত্রুটির পেজ বা অন্য হোস্ট অপ্রত্যাশিত মানের কারণ হতে পারে। শেষ হেডার তালিকার বদলে রিডাইরেক্টের পথ নিয়ে বিস্তারিত দেখতে Redirect Checker ব্যবহার করুন।
HTTP রেসপন্স হেডারের একটি উদাহরণ পড়ুন
এই কাল্পনিক রেসপন্সে আলাদা ফিল্ড কীভাবে আলাদা প্রশ্নের উত্তর দেয় তা দেখানো হয়েছে। এটি সংগ্রহ করা বাস্তব ফলাফল বা সব পেজে কপি করার কনফিগারেশন নয়।
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Robots-Tag: noindex
200 সফল রেসপন্স বোঝায়। Content-Type UTF-8 এনকোডিংয়ের HTML ঘোষণা করে। Cache-Control ক্যাশের নির্দেশনা দেয়, আর X-Robots-Tag ইনডেক্সিং নির্দেশনা দেয়। তাই কার্যকর রেসপন্সেও noindex থাকতে পারে। HTTP সাফল্য মানেই পেজটি সার্চ ফলাফলের জন্য তৈরি, এমন নয়।
টেবিলে হেডারের নাম ছোট হাতের অক্ষরে স্বাভাবিকীকরণ করে দেখানো হয়। বড় হাতের অক্ষর ব্যবহার করলেই সেটি আলাদা ফিল্ড হয় না। MDN-এর হেডার নির্দেশিকা অনুরোধ ও রেসপন্সের ফিল্ডের পার্থক্য ব্যাখ্যা করে। এই পরীক্ষক রেসপন্স দেখায়; আপনার নিজের ব্রাউজার সেশনের কুকি, পছন্দ বা পরিচয় যাচাইয়ের তথ্যের তালিকা দেখায় না।
ক্যাশ ও ইনডেক্সিং আলাদা সিদ্ধান্ত হিসেবে দেখুন
নির্দিষ্ট সমস্যা দেখার সময় হেডারের নাম দিয়ে টেবিল ফিল্টার করুন। আগে রিসোর্সের প্রয়োজন ঠিক করুন। বারবার বদলানো HTML, সংস্করণযুক্ত ফাইল ও ইচ্ছাকৃতভাবে সার্চ থেকে বাদ রাখা নথির নীতি একই হতে হবে না।
| হেডার | পর্যালোচনার দরকারি প্রশ্ন |
|---|---|
content-type |
ঘোষিত ফরম্যাট প্রত্যাশিত রিসোর্সের সঙ্গে মেলে, নাকি রিডাইরেক্ট অন্য রেসপন্সে গেছে? |
cache-control |
ক্যাশের নীতি রিসোর্সের আপডেট ও গোপনীয়তার চাহিদা পূরণ করে? |
etag বা last-modified |
শর্তসাপেক্ষ অনুরোধের জন্য যাচাইসূচক আছে? থাকলেই পুনরায় যাচাই কাজ করছে প্রমাণ হয় না। |
vary |
ক্যাশ বাছাইয়ের জন্য অনুরোধের কোন হেডারের পার্থক্য রেসপন্স উল্লেখ করে? |
x-robots-tag |
এই URL-এ দেখা noindex ইচ্ছাকৃত? |
no-cache মানে “কখনো সংরক্ষণ নয়” নয়। এটি সংরক্ষণ করতে দেয়, তবে পুনর্ব্যবহারের আগে যাচাই চায়। no-store ক্যাশকে রেসপন্স না রাখতে বলে। MDN-এর Cache-Control ব্যাখ্যা পার্থক্যটি দেখায়। এই পরীক্ষা ক্যাশ থেকে কতবার রেসপন্স এসেছে তা মাপে না এবং আগের সংরক্ষিত কপি মুছে দেয় না।
ইনডেক্সিং নির্দেশনা কনটেন্টের হালনাগাদ থাকার বিষয় থেকে আলাদা। ইনডেক্স হওয়ার কথা এমন পেজ অপ্রত্যাশিত noindex দিলে বদলানোর আগে দায়ী অ্যাপ্লিকেশন, সার্ভারের সেটিং বা রেসপন্সের নিয়ম খুঁজুন। HTML নির্দেশনাও দেখতে Noindex Checker ব্যবহার করুন। Google-এর noindex নথি নির্দেশনা বোঝায়; এখানে তা দেখা Google-এর বর্তমান ইনডেক্সের অবস্থা প্রমাণ করে না।
নিরাপত্তার হেডার সম্পর্কে পর্যবেক্ষণ বুঝুন
Screpy কিছু নির্দিষ্ট ঘোষণা পর্যালোচনার জন্য তুলে ধরে। কোনো ফলাফলকে কনফিগারেশনের প্রশ্ন হিসেবে দেখুন, দুর্বলতার রিপোর্ট বা না-বোঝা নীতি প্রকাশিত সাইটে কপি করার পরামর্শ হিসেবে নয়।
| পর্যবেক্ষণ | পরীক্ষাটি যা নির্ধারণ করে এবং যা করে না |
|---|---|
| HSTS পর্যালোচনা | HTTPS রেসপন্সে ধনাত্মক max-age খোঁজে। পুরো HTTPS বাস্তবায়ন বা সার্টিফিকেট যাচাই করে না। |
| CSP অনুপস্থিত | HTML হিসেবে ঘোষিত রেসপন্সে Content-Security-Policy খোঁজে। থাকলেই তার নির্দেশনা অ্যাপ্লিকেশনকে সুরক্ষিত রাখছে নিশ্চিত নয়। |
| ফ্রেমে বসানোর পর্যালোচনা | CSP-তে frame-ancestors বা স্বীকৃত X-Frame-Options মান খোঁজে। পেজ অন্য জায়গায় বসানো যাবে কি না তার কাজের ওপর নির্ভর করে। |
| MIME শনাক্তকরণ পর্যালোচনা | X-Content-Type-Options-এ nosniff আছে কি না দেখে। আসল ফাইলের বিষয়বস্তু বা প্রতিটি ব্রাউজারের আচরণ পরীক্ষা করে না। |
তথ্যমূলক বার্তা বা কোনো নীতি না পাওয়া দুর্বলতার প্রমাণ নয়। একইভাবে হেডার থাকলেই নীতি কার্যকর হয় না। MDN-এর CSP নির্দেশিকা, কার্যকরভাবে বাধ্য করা নীতি এবং Content-Security-Policy-Report-Only-এর পার্থক্য করে। দ্বিতীয়টি লঙ্ঘন জানায়, কিন্তু সেই বিধিনিষেধ কার্যকর করে না। সেটি দেখা মানেই বাধ্যতামূলক নীতি আছে, এমন নয়।
অ্যাপ্লিকেশনের আসল রিসোর্স ও এমবেডিংয়ের চাহিদা অনুযায়ী পরিবর্তন বিচার করুন। পরীক্ষক নিরাপত্তার গ্রেড দেয় না, সার্টিফিকেট দেখে না এবং সব নির্দেশনা যাচাই করে না। HTML-এর ভেতরে অনিরাপদ রিসোর্সের ঠিকানা আলাদাভাবে দেখতে Mixed Content Checker ব্যবহার করুন।
পুনরাবৃত্ত ও গোপন মানের অর্থ বুঝুন
হেডারের সংখ্যা স্বাভাবিকীকরণ করা আলাদা নামের সংখ্যা। উপস্থিতির কলাম একটি নাম কতবার এসেছে তা দেখায় এবং পুনরাবৃত্ত সাধারণ মান দৃশ্যমান থাকে। একাধিকবার থাকা স্বয়ংক্রিয়ভাবে ত্রুটি নয়। ওই ফিল্ডে এমন গঠন বৈধ কি না এবং সম্মিলিত নীতি ইচ্ছাকৃত কি না দেখুন।
সংবেদনশীল কুকি, পরিচয় যাচাই ও চিহ্নিত গোপন মান আড়াল বা পরিষ্কার করা হয়। গোপন মান মানে হেডার অনুপস্থিত নয়, আর তার উপস্থিতি কুকির নিরাপত্তা মূল্যায়নও নয়। শেয়ার করার রিপোর্টে আড়াল করা মান আবার বসাবেন না। গোপন বিবরণ শুধু উপযুক্ত ব্যক্তিগত ডিবাগিং পরিবেশে দেখুন।
সার্চ বক্স সব মানে খুঁজবে ধরে না নিয়ে cache-control-এর মতো নাম দিয়ে ফিল্টার করুন। তুলনার জন্য রিপোর্টের সঙ্গে পরীক্ষিত URL ও সময় রাখুন। কোনো ফিল্ড থাকা বা না-থাকা শেষ স্ট্যাটাস, রিসোর্সের ধরন ও কভারেজ বার্তার সঙ্গে মিলিয়ে বুঝুন।
আংশিক পরীক্ষা ও HTTP ত্রুটির পার্থক্য করুন
সার্ভারের ত্রুটির রেসপন্স দেওয়া এবং পরীক্ষকের সার্ভারে পৌঁছাতে না পারা আলাদা ফলাফল। অনুপস্থিত সারি ব্যাখ্যা করার আগে কভারেজের বার্তা পড়ুন।
| ফলাফল | অর্থ ও পরের করণীয় |
|---|---|
হেডারসহ শেষ 404 বা 500 |
রেসপন্স দেখা গেছে। URL নিশ্চিত করে রিসোর্স বা সার্ভারের ত্রুটি দেখুন; সংযোগ সফল মানেই পেজ কার্যকর নয়। |
| আংশিক রেসপন্সের ধাপ | কিছু ধাপ দেখা গেছে, কিন্তু শেষ রেসপন্স পরীক্ষা করা যায়নি। শেষ হেডার অজানা; অনুপস্থিত বলে নিশ্চিত নয়। |
| সময় শেষ বা উৎস অনুপলব্ধ | চাওয়া রেসপন্স পাওয়া যায়নি। আবার চেষ্টা করার আগে প্রকাশ্য প্রবেশাধিকার, ঠিকানা ও রিডাইরেক্ট দেখুন। |
পরীক্ষক সীমিত সংখ্যক রিডাইরেক্ট অনুসরণ করে এবং সীমিত সময় অপেক্ষা করে। লুপ, অপ্রবেশযোগ্য গন্তব্য বা সমর্থিত সীমার বাইরে রেসপন্স পরীক্ষাকে অসম্পূর্ণ রাখতে পারে। তখন শেষ হেডারের ফাঁকা তালিকাকে অনুপস্থিত নিরাপত্তা হেডারের তালিকা ভাববেন না।
ব্যক্তিগত নেটওয়ার্কের ঠিকানা, লগইন দরকার এমন পেজ ও আপনার ব্রাউজারের কুকি লাগে এমন অনুরোধ ফর্মের আওতায় নেই। প্রবেশে বাধা পাওয়াও Googlebot বা অন্য প্রকৃত ব্যবহারকারী কী পায় তার প্রমাণ নয়।
প্রকাশের পরে হেডার তুলনা করুন
বদলানোর আগে সঠিক URL, শেষ রেসপন্স, পরীক্ষার সময় এবং কোন ফিল্ড বদলানোর কথা তা লিখে রাখুন। শুরুর অবস্থা রাখতে রিপোর্ট এক্সপোর্ট করুন। কাঙ্ক্ষিত কনফিগারেশন প্রকাশের পরে একই URL পরীক্ষা করে সংশ্লিষ্ট মান তুলনা করুন, শুধু হেডার বা সতর্কতার সংখ্যা নয়। নিয়ম অন্য ধরনের রিসোর্সেও প্রযোজ্য হলে তার একটিও পরীক্ষা করুন।
ব্রাউজারে ভিন্ন কিছু দেখলে Network প্যানেল খুলে পেজ আবার লোড করুন এবং সংশ্লিষ্ট অনুরোধ দেখুন। রিডাইরেক্টের পরের URL, পদ্ধতি ও লগইন অবস্থা তুলনা করুন। ক্যাশে থাকা বা ব্যক্তিভিত্তিক রেসপন্স অন্য স্থান থেকে করা প্রকাশ্য অনুরোধের সমান নাও হতে পারে। এই ফর্ম আপনার কুকি পাঠায় না বা নিজস্ব পরিচয় যাচাইয়ের হেডার যোগ করতে দেয় না।
অন্য টুল GET-এর বদলে HEAD ব্যবহার করেছে কি না দেখুন। RFC 9110 জানায়, HEAD রেসপন্সে মূল অংশ থাকে না এবং কনটেন্ট তৈরির সময় নির্ধারিত কিছু ফিল্ড বাদ যেতে পারে। Screpy GET ব্যবহার করে, কিন্তু মূল অংশ ডাউনলোডের আগে থামে। পদ্ধতি ও অনুরোধের শর্ত মেলালে পার্থক্যের কারণ খুঁজতে সুবিধা হয়; সব সার্ভার রেসপন্স এক হয়ে যায় না।