Header, Keep-Alive, Compression ও CORS

এই Lesson শেষে তুমি পারবে

• যেকোনো HTTP Header-এর তালিকা পড়তে: Request, Response আর Representation Header আলাদা করতে, End-to-end আর Hop-by-hop Header চিনতে; নামগুলো কেন Case-insensitive আর HTTP/2-এর Pseudo-header কী, তা জানতে।
• Production-এ দরকারি Header ঠিকভাবে ব্যবহার করতে: Host, Accept*, Content-Type, Content-Length, Authorization, Cookie, X-Forwarded-For আর Forwarded, Request ID আর traceparent, আর প্রধান Security Header।
• Keep-alive আর Persistent Connection বোঝাতে, Load Balancer আর App-এর Idle Timeout এমনভাবে ঠিক করতে যাতে কখনো 502 না আসে, আর HTTP Keep-alive আর TCP Keepalive-এর পার্থক্য বলতে।
• Compression কীভাবে ঠিক হয় তা বোঝাতে, সংখ্যা দিয়ে gzip, Brotli আর zstd-এর মধ্যে বাছতে, কী কখনো Compress করবে না তা জানতে, আর Dictionary Compression ও BREACH আক্রমণ বোঝাতে।
• Same-origin Policy আর CORS শুরু থেকে শেষ বোঝাতে: Origin, Simple আর Preflight করা Request, প্রতিটা Access-Control-* Header, Credential, Cache, আর যেসব ভুল Configuration CORS-কে Data ফাঁসের রাস্তা বানিয়ে দেয়।
• এসব Design আর Debugging-এ কাজে লাগাতে: Header কোথায় বসাবে, Preflight কীভাবে এড়াবে, আর কোন লক্ষণ কোন দিকে ইশারা করে।

#এই Lesson কোথায় বসে

Lesson ১.১-এ আমরা HTTP Message-এর গড়ন দেখেছি (প্রথম লাইন, Header, ফাঁকা লাইন, Body), সাথে রোজকার Header-এর একটা Table। Lesson ১.৩-এ শিখেছি Set-Cookie, Cookie আর তাদের Attribute; Lesson ১.৯-এ HSTS; আর Lesson ১.১০-এ দেখেছি নতুন TCP Connection কেন ধীর। Lesson ২.১-এ HTTP-কে ১.০ থেকে ৩ পর্যন্ত হেঁটে দেখেছি, আর Lesson ২.২-এ Method আর Status Code।

এই Lesson প্রতিটা Request আর Response-এর চারপাশের Metadata নিয়ে: Header, যে Connection-এর ওপর দিয়ে এরা যায়, Body কীভাবে ছোট করা হয়, আর Browser-এর সেই নিয়ম যা ঠিক করে কোন Page কোন Response পড়তে পারবে। চারটাই তুমি প্রতি সপ্তাহে Web Server, Load Balancer আর CDN-এ Configure করবে, আর চারটা থেকেই Production-এর চিরচেনা দুর্ঘটনাগুলো ঘটে।

#Header-এর গড়ন

Header হলো নাম আর মানের একটা জোড়া, মানে Metadata: Name: value। HTTP/1.1-এ প্রতিটা একটা করে লেখার লাইন; সবগুলো মিলে প্রথম লাইন আর Body-র আগের ফাঁকা লাইনের মাঝখানে বসে।

GET /api/orders?page=2 HTTP/1.1
Host: shop.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) … Chrome/141.0 Safari/537.36
Accept: application/json
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: bn-BD, en;q=0.8
Authorization: Bearer eyJhbGciOi…
Cookie: sid=9f2c…; lang=bn

যে নিয়মগুলোতে মানুষ হোঁচট খায়:

• নাম Case-insensitive। Content-Type, content-type আর CONTENT-TYPE একই Header। মান সাধারণত Case-sensitive (একটা Token, একটা Cookie)।
• আলাদা আলাদা Header-এর মধ্যে ক্রমের কোনো দাম নেই, তবে একই Header বারবার এলে আছে।
• একই Header বারবার আসতে পারে, আর সেগুলোর মান কমা দিয়ে জোড়া যায়: দুটো Accept-Encoding লাইন মানে দুটো মান সহ একটা লাইন। বিখ্যাত ব্যতিক্রম Set-Cookie: এর মানে কমা থাকে (তারিখে), তাই প্রতিটা Cookie-র নিজের লাইন লাগে।
• Accept* Header-এ Quality Value (;q=0.8) ০ থেকে ১ পর্যন্ত পছন্দের ক্রম জানায়; q=0 মানে “কখনোই না”।
• নিজের বানানো Header চলে। পুরনো X- উপসর্গের রীতি ২০১২ সালে আনুষ্ঠানিকভাবে বাদ দেওয়া হয়েছে, কিন্তু X-Request-ID আর X-Forwarded-For এত ছড়িয়ে গেছে যে নাম আর বদলানো যায় না।

#চার রকম Header

যা Hop-by-hop না, তা-ই End-to-end: প্রতিটা Proxy আর Cache পার হয়ে এটাকে শেষ প্রাপকের কাছে অপরিবর্তিত পৌঁছাতে হবে। Hop-by-hop Header শুধু এই Link-এর কথা বলে (TCP Connection খোলা রাখো, এই Link-এ Body টুকরো টুকরো আসছে), তাই সামনে পাঠানোর আগে Proxy এগুলো সরাতে বাধ্য, সাথে Connection-এর ভেতরে যেসব Header-এর নাম লেখা আছে সেগুলোও। Proxy চাইলে নিজের Header যোগও করতে পারে; X-Forwarded-For আর Via এভাবেই আসে।

#HTTP/2 আর HTTP/3-এ Header

মানে হুবহু এক, কিন্তু তারের ওপর এরা আর লেখা হিসেবে যায় না:

• Request Line ভেঙে হয় কোলন দিয়ে শুরু হওয়া Pseudo-header: :method, :scheme, :authority (Host-এর বদলে) আর :path। Response-এ থাকে :status। Pseudo-header সবার আগে আসে।
• সব নাম ছোট হাতের হতে হবে। বড় হাতের নাম থাকলে Message-টা ভুল গঠনের ধরা হয়।
• Connection-নির্দিষ্ট Header নিষেধ: Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding আর Upgrade। TE-তে শুধু trailers লেখা চলে।
• Header Compress হয়ে যায়: HTTP/2-তে HPACK, HTTP/3-তে QPACK। তাই প্রতি Request-এ একই ২ KB Cookie পাঠালেও প্রথমবারের পরে খরচ মাত্র কয়েক Byte (Lesson ২.১)।

Proxy হরদম এক Version থেকে আরেকটায় অনুবাদ করে: Browser থেকে Edge পর্যন্ত HTTP/2, Edge থেকে App পর্যন্ত HTTP/1.1।

#আকারের সীমা

Standard-এ কোনো সীমা নেই, কিন্তু প্রতিটা Server-এর একটা আছে, আর সীমা পেরোলে তোমার Code চলার আগেই Request ফেরত যায়: Nginx Default-এ প্রতি Header লাইনে ৮ KB দেয় (large_client_header_buffers 4 8k), Apache প্রতি Field-এ ৮,১৯০ Byte, Node.js সব Header মিলিয়ে ১৬ KB। উত্তর আসে 431 Request Header Fields Too Large, অথবা “Request Header Or Cookie Too Large” লেখা 400। সাধারণত দোষী Cookie: মিলে যাওয়া প্রতিটা Cookie প্রতিটা Request-এ যায়, Image-এর Request-এও। প্রতিটা Hop-এর (CDN, Load Balancer, Proxy, App) সীমা আলাদা, আর সবচেয়ে ছোটটাই জেতে।

#যেসব Header সত্যিই দরকারি

রোজকার Table আছে Lesson ১.১-এ। এখানে দেখব জরুরি Header-গুলো আসলে কী করে, আর কোথায় গোলমাল বাধে।

#আসল Client কে? X-Forwarded-For আর Forwarded

Load Balancer-এর পেছনে App-এর TCP সঙ্গী হলো Load Balancer, ব্যবহারকারী না (Lesson ১.৭: Load Balancer-ও এক রকম NAT)। তাই Edge একটা Header-এ Client-এর Address লিখে দেয়:

X-Forwarded-For: 203.0.113.7, 198.51.100.10
X-Forwarded-Proto: https
X-Forwarded-Host: shop.example.com
Forwarded: for=203.0.113.7;proto=https;host=shop.example.com, for=198.51.100.10

প্রতিটা Proxy নিজের দেখা Address তালিকার শেষে যোগ করে, তাই তালিকা বাঁ থেকে ডানে বাড়ে: প্রথমে আসল Client, শেষে শেষ Proxy। Forwarded (RFC 7239) হলো তিনটা X-Forwarded-* Header-এর Standard, গোছানো রূপ; দুটোই চালু।

ফাঁদটা হলো: Client নিজেও X-Forwarded-For পাঠাতে পারে, আর Proxy সেটার শেষেই যোগ করে। বাঁয়ের মানটা Client যা লিখেছে তা-ই। বিশ্বাস করো শুধু তোমার নিজের Proxy-র যোগ করা এন্ট্রি: সামনে একটা বিশ্বস্ত Proxy থাকলে ডানের শেষ মানটা নাও; দুটো থাকলে ডান থেকে দ্বিতীয়টা। আরও ভালো: সবচেয়ে বাইরের Proxy Header-টা পুরো নতুন করে লিখুক। Framework-গুলোতে ঠিক এর জন্যই Setting আছে (“Trusted Proxies”, “Hop-এর সংখ্যা”), আর এটা ভুল হলে Rate Limiting, Geo-blocking, Audit Log আর IP Allowlist সব ভেঙে পড়ে।

#একটা Request-এর পিছু নেওয়া: X-Request-ID আর traceparent

একটা Click একটা CDN, একটা Load Balancer, একটা API Gateway আর পাঁচটা Service পেরোতে পারে। ওই Click-এর সব Log লাইন খুঁজে পেতে Edge-এ Request-কে একটা ID দাও, তারপর সেটা হাতে হাতে পাঠাও:

• X-Request-ID (বা X-Correlation-ID): Client না পাঠালে প্রথম Proxy একটা Random ID বানায়, সেটা প্রতিটা Service-এ যায়, প্রতিটা Log লাইনে লেখা হয়, আর Response-এও ফেরত আসে যাতে ব্যবহারকারী Support-কে নম্বরটা বলতে পারে।
• traceparent (W3C Trace Context Standard, OpenTelemetry এটাই ব্যবহার করে): 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 = Version, ১৬ Byte-এর Trace ID, ৮ Byte-এর Parent Span ID, Flag (01 = Sample করা)। প্রতিটা Service Trace ID রেখে দেয় আর Parent ID-র জায়গায় নিজের Span বসায়, ফলে Tracing Tool পুরো Call-এর গাছটা আঁকতে পারে। tracestate বাড়তি Vendor তথ্য বয়ে নেয়। Chapter 46 এর ওপরেই দাঁড়াবে।

#Security Header, সংক্ষেপে

বেশিরভাগ Security Header এক লাইনের, খরচও নেই, তাই Edge-এ এক জায়গা থেকে বসিয়ে দাও। আক্রমণগুলো বোঝাবে Chapter 35; এখানে শুধু কোন Header কী কাজে।

তথ্য ফাঁস করে এমন জিনিসও সরাও: Server-এ Version নম্বর, আর X-Powered-By: Express বা PHP-র পরিচয়। পুরনো X-XSS-Protection Header এখন অচল; তার বদলে CSP ব্যবহার করো।

#Keep-alive আর Persistent Connection

ছোট একটা Request-এর সবচেয়ে দামি অংশ হলো Connection খোলা: TCP-তে এক Round Trip, TLS 1.3-এ আরও এক (TLS 1.2-তে দুই), তারপর TCP শুরু করে ছোট Congestion Window নিয়ে (Lesson ১.১০)। ৫০ ms-এর পথে প্রথম Request Byte যাওয়ার আগেই ১০০ ms, অথচ Response বানাতে হয়তো লাগে ৫ ms।

• HTTP/1.0 প্রতিটা Response-এর পরে Connection বন্ধ করত। কিছু Client আর Server বারবার ব্যবহারের জন্য একটা অনানুষ্ঠানিক Connection: keep-alive Header জুড়ে দিত।
• HTTP/1.1 টিকে থাকাকেই নিয়ম বানিয়েছে: কোনো পাশ Connection: close না পাঠালে Response-এর পরেও Connection খোলা থাকে। তাই HTTP/1.1 Request-এ Connection: keep-alive লেখা বাড়তি।
• ঐচ্ছিক Keep-Alive: timeout=5, max=100 Response Header একটা ইঙ্গিত মাত্র: “অলস অবস্থায় ৫ সেকেন্ড পর্যন্ত আর সর্বোচ্চ ১০০টা Request পর্যন্ত এই Connection রাখব”। Client চাইলে উপেক্ষা করতে পারে; HTTP/2 আর HTTP/3-এ এটা নেই, বরং নিষেধ।
• কী বাঁচে: প্রথমটার পরের প্রতিটা Request-এ TCP Handshake আর TLS দর-কষাকষি, সেই Handshake-এর Server CPU, TIME_WAIT-এ পড়ে থাকা Socket, আর ঠান্ডা Connection-এর Slow Start।
• HTTP/1.1-এর সীমা: এক Connection-এ একবারে একটাই Request (Browser-এ Pipelining কখনো চালু হয়নি), তাই Browser প্রতি Host-এ প্রায় ৬টা Connection খোলে। HTTP/2 প্রতি Origin-এ একটা Connection-এই সব চালায়; HTTP/3 একই কাজ করে QUIC-এর ওপর।

#Idle Timeout, আর যে দৌড় থেকে 502 আসে

অলস Connection Memory, একটা File Descriptor আর TLS State আটকে রাখে, তাই প্রতিটা Server একটা Idle Timeout-এর পরে এগুলো বন্ধ করে, অনেকে আবার N সংখ্যক Request-এর পরেও। চেনা Default:

ঝামেলা শুরু হয় যখন এদের দুজন মুখোমুখি হয়। Load Balancer প্রতিটা Backend-এর সাথে Connection-এর একটা Pool রাখে আর বারবার ব্যবহার করে। Backend-এর Timeout যদি Load Balancer-এরটার চেয়ে ছোট হয়, তাহলে Backend একটা অলস Connection ঠিক সেই মুহূর্তে বন্ধ করে যখন Load Balancer তার ওপর নতুন Request পাঠাচ্ছে। Request গিয়ে পড়ে বন্ধ Socket-এ, Backend TCP Reset দিয়ে উত্তর দেয়, আর Load Balancer ফেরত দেয় 502 Bad Gateway। খুব অল্প Request-এ ঘটে, কম Traffic-এ বেশি, আর App-এর Log-এ কিছুই থাকে না। Cloud Load Balancer-এর পেছনে “হঠাৎ হঠাৎ 502”-এর এটা অন্যতম প্রধান কারণ।

নিয়মটা হলো: পুরো শিকলে, যে পাশ Request পাঠায়, অলস Connection তাকেই আগে বন্ধ করতে হবে। তাই Backend-এর Keep-alive Timeout Load Balancer-এর Idle Timeout-এর চেয়ে বেশি হবে (যেমন ৬০ s-এর ALB-এর পেছনে ৬৫ s), আর Client-এর Pool Timeout হবে তার Server-এরটার চেয়ে কম।

#Connection Pool

প্রতিটা গুরুতর Client একটা Pool রাখে: Browser প্রতি Origin-এ, HTTP Library প্রতি Host-এ, Load Balancer আর Reverse Proxy প্রতি Backend-এ, আর Database Driver প্রতি Database-এ। যে Setting-গুলো জানা দরকার:

• প্রতি Host-এ সর্বোচ্চ Connection: Backend-এর ওপর চাপ বেঁধে রাখে; খুব কম হলে Request Client-এর ভেতরেই লাইনে দাঁড়ায়।
• Idle Timeout: Server-এরটার চেয়ে ছোট, ওপরের কারণে।
• সর্বোচ্চ আয়ু: কয়েক মিনিট পরপর Connection নতুন করো, যাতে DNS বা Load Balancer-এর পেছনে আসা নতুন Backend-ও Traffic পায়, আর Scale-out-এর পরে দীর্ঘজীবী Connection সব চাপ পুরনো Server-এ আটকে না রাখে।
• যাচাই বা আবার চেষ্টা: Pool-এর Connection হয়তো অন্য পাশ বন্ধ করে দিয়েছে। Client নিজে থেকে আবার পাঠায় শুধু সেই Idempotent Request, যা কোনো Response Byte আসার আগেই ব্যর্থ হয়েছে (Lesson ২.২); POST-এর জন্য লাগে Idempotency Key।
• Reverse Proxy থেকে Backend: Nginx ঐতিহাসিকভাবে Configure না করলে Upstream Connection আবার ব্যবহার করত না (upstream Block-এ keepalive 32;, সাথে proxy_http_version 1.1 আর ফাঁকা Connection Header)। এটা ছাড়া প্রতিটা Request App-এর দিকে নতুন Connection খোলে, আর চাপের সময় Ephemeral Port ফুরিয়ে যায় (Lesson ১.৯)।

#HTTP Keep-alive আর TCP Keepalive এক জিনিস না

নামে মিল, আর কোনো মিল নেই:

TCP Keepalive আর Application Heartbeat (HTTP/2-এর PING Frame, WebSocket Ping) বিস্তারিত আছে Lesson ১.১০-এ।

#Compression

লেখা খুব ভালো Compress হয়: HTML, CSS, JavaScript, JSON, SVG আর XML ভরা থাকে একই শব্দ আর Markup-এ। পাঠানোর আগে এগুলো ছোট করলে Bandwidth বাঁচে আর Page তাড়াতাড়ি আসে, বিশেষ করে Mobile Network-এ।

#কীভাবে ঠিক হয়

1. Client জানায় সে কী কী খুলতে পারে: Accept-Encoding: gzip, deflate, br, zstd (চাইলে q-value সহ, যেমন br;q=1.0, gzip;q=0.8)।
2. Server নিজের জানা একটা বেছে নেয়, Body Compress করে, আর লেবেল লাগায়: Content-Encoding: br। Content-Length এখন Compress করা মাপ।
3. সাথে দেয় Vary: Accept-Encoding, যাতে Cache প্রতিটা Encoding-এর আলাদা কপি রাখে (Vary বোঝাবে Lesson ২.৪)।
4. Browser খুলে Render করে। Client কোনো Accept-Encoding না পাঠালে Server-এর উচিত Body যেমন আছে তেমন পাঠানো (identity Coding)।

Content-Encoding End-to-end, এটা Representation-এর বর্ণনা; Hop-by-hop Transfer-Encoding (chunked) একদম আলাদা জিনিস। Request-এর Body Compress করা (POST-এ Content-Encoding) সম্ভব, কিন্তু কম দেখা যায়, আর Server স্পষ্টভাবে সমর্থন করলেই চলে; নাহলে 415 আশা করো।

#gzip বনাম Brotli বনাম zstd

এই Lesson-এর Animation-এর হিসাব: ৪১২ KB-এর একটা JavaScript Bundle gzip-এ হয় প্রায় ১১৮ KB, আর Level 11-এর Brotli-তে ৯৮ KB। Static File Build-এর সময় আগেই Compress করে রাখো (app.js.br, app.js.gz), Server ঠিক File-টা বেছে দেবে; Dynamic Response চলতে চলতে মাঝারি Level-এ Compress করো। অনেক CDN এর সবটাই তোমার হয়ে করে দেয়।

#কী Compress করবে না

• আগেই Compress করা Format: JPEG, PNG, WebP, AVIF, GIF, MP4 আর অন্য Video, MP3, WOFF2 Font, ZIP, ভেতরে Compress করা Stream সহ PDF। gzip এদের ০–২% বাঁচায়, উল্টো বড়ও করে ফেলতে পারে, অথচ দুই পাশেই CPU খায়।
• খুব ছোট Response: প্রায় ১ KB-এর নিচে যা বাঁচে তা এক Packet-এর চেয়েও কম, আর Compression-এর নিজস্ব Header মিলে উল্টো বড় হতে পারে।
• যে Response-এ গোপন তথ্য আর Attacker-এর লেখা মেশানো, যদি না BREACH-এর বিরুদ্ধে ব্যবস্থা থাকে (নিচে)।
• Default-এর ফাঁদ: Nginx-এ Default হলো gzip off, আর তুমি application/json, text/css, application/javascript, image/svg+xml যোগ না করা পর্যন্ত gzip_types শুধু text/html ধরে। “Mobile-এ আমাদের API ধীর” ধরনের অনেক Ticket-এর পেছনে থাকে Compress না করা JSON।

#Compression Dictionary Transport

সাধারণ Compression প্রতিটা Response-এ শূন্য থেকে শুরু করে। Compression Dictionary Transport (২০২৫ সালে IETF-এ Standard হয়েছে; Chrome-এ Version 130 থেকে) আগে নামানো একটা File-কে পরেরটার Dictionary বানিয়ে দেয়:

1. Server app.v1.js পাঠায় Use-As-Dictionary: match="/app.*.js" সহ। Browser এটাকে মিলে যাওয়া URL-এর জন্য Dictionary হিসেবে রেখে দেয়।
2. Deploy-এর পরে Browser app.v2.js চায় Available-Dictionary: :hash-of-v1: সহ (রাখা File-টার SHA-256 Hash), আর Accept-Encoding-এ যোগ করে Dictionary Coding dcb (Brotli) আর dcz (zstd)।
3. Server-এর কাছে v1 থাকলে সে v2-কে v1-এর সাপেক্ষে Compress করে উত্তর দেয় Content-Encoding: dcz: প্রায়ই শুধু বদলানো Byte-গুলো, ১০০ KB-এর বদলে কয়েক KB। Response-কে Available-Dictionary অনুযায়ীও Vary করতে হয়।

ঘনঘন Deploy হওয়া JavaScript Bundle-এ, আর বড় একই কাঠামোর API Response-এ (সাধারণ Response থেকে বানানো Custom Dictionary দিয়ে) এটা দারুণ কাজ দেয়।

#Compression যখন গোপন তথ্য ফাঁস করে: CRIME আর BREACH

Compression বারবার আসা লেখা খুঁজে দ্বিতীয় কপিটাকে একটা ছোট পেছনের-রেফারেন্স দিয়ে বদলে দেয়। Attacker যদি গোপন তথ্যের সাথে একই Compress করা Message-এ নিজের অনুমান ঢোকাতে পারে, তাহলে ঠিক অনুমানে Message ছোট হয়ে যায়, আর সেই দৈর্ঘ্য TLS-এর ভেতর দিয়েও দেখা যায়।

• CRIME (২০১২) আক্রমণ করেছিল TLS স্তরের Compression-এ (আর SPDY-র Header Compression-এ), Cookie চুরি করতে। এরপর সব জায়গায় TLS Compression বন্ধ হয়, আর TLS 1.3 এটা বাদই দিয়েছে; HPACK এমনভাবে বানানো যাতে Header Compression এভাবে ফাঁস না করে।
• BREACH (২০১৩) আক্রমণ করে HTTP Body-র Compression-এ। এর জন্য তিনটা জিনিস একসাথে লাগে: Body Compress করা, তাতে গোপন তথ্য আছে (একটা CSRF Token), আর তাতে Attacker-এর দেওয়া লেখা ফিরে আসে (URL-এর একটা Search শব্দ)। Attacker-এর Page ভুক্তভোগীর Browser-কে দিয়ে হাজারো অনুমান পাঠায়, আর Network-এ বসে Response-এর মাপ দেখে।

প্রতিরক্ষা, যেকোনো একটাই আক্রমণ ভেঙে দেয়: প্রতি Response-এ গোপন তথ্যকে মুখোশ পরাও (প্রতিবার Token-কে একটা নতুন Random মানের সাথে XOR করো, Django আর Rails যেমন করে), SameSite Cookie যাতে Cross-site Request লগইন ছাড়াই আসে, গোপন তথ্য আর ফিরে আসা লেখা মেশানো Response Compress কোরো না, আর Rate Limit দাও। BREACH-এর জন্য কেউ পুরো Site-এর Compression বন্ধ করে না।

#CORS, শুরু থেকে শেষ

#Same-origin Policy

Browser অনেক Site-এর Code পাশাপাশি চালায়, সবগুলোর হাতেই ব্যবহারকারীর Cookie। কোনো নিয়ম না থাকলে তুমি যে Page-এই যাও, তার Script তোমার Cookie দিয়ে তোমার Bank-এর API Call করে তোমার Balance পড়ে ফেলতে পারত। Same-origin Policy (SOP) এটা নিষেধ করে: একটা Script অবাধে Response পড়তে পারে শুধু নিজের Origin থেকে।

Origin মানে Scheme + Host + Port। https://shop.example.com-এর (Port 443 ধরে নেওয়া) সাথে তুলনা:

Site আরেকটু বড়: Scheme আর নিবন্ধনযোগ্য Domain। shop.example.com আর api.example.com একই Site, কিন্তু আলাদা Origin। এজন্যই SameSite Cookie (Lesson ১.৩, এটা Site ধরে কাজ করে) এদের মধ্যে যায়, অথচ Same-origin Policy (Origin ধরে) তখনো খাটে।

নিয়মটা মানুষ যতটা ভাবে তার চেয়ে সরু। এটা অন্য জায়গায় Request পাঠানো বা অন্য Origin-কে বসানো আটকায় না: <img>, <script>, <link rel=stylesheet>, <iframe>, <video> আর HTML Form জমা দেওয়া, সবই Cross-origin চলে, ১৯৯০-এর দশকে যেমন চলত। এটা আটকায় পড়া: Script Cross-origin fetch-এর Response দেখতে পারে না, Canvas-এ আঁকা Cross-origin Image-এর Pixel পড়তে পারে না, Cross-origin Frame-এর ভেতরে উঁকি দিতে পারে না।

#CORS: Server নিজে দরজা খোলে

Cross-Origin Resource Sharing (CORS) হলো নিয়ন্ত্রিত ব্যতিক্রম। Browser Server-কে জানায় কোন Origin জিজ্ঞেস করছে (Origin Request Header, Browser নিজে বসায়, Page-এর Script এটা জাল করতে পারে না), আর Server Access-Control-* Header দিয়ে জানায় কে পড়তে পারবে। উত্তরে Page-এর Origin-কে অনুমতি না দিলে Browser Response-টা Script-এর কাছ থেকে লুকিয়ে রাখে।

মানে Same-origin Policy হলো দেয়াল, আর CORS হলো সেই দরজা যেটা Server খুলবে কি না ঠিক করে। নোটের উদাহরণ: https://shop.example.com-এর একটা Front-end https://api.example.com-কে Call করছে। Browser দেখে API ওই Origin-কে অনুমতি দিয়েছে কি না; দিলেই কেবল JavaScript Response পড়তে পারে।

#Simple Request

কিছু Request CORS আসার আগেই সাধারণ HTML Form দিয়ে পাঠানো যেত, তাই CORS এগুলো সরাসরি পাঠায়, বাড়তি কোনো Round Trip ছাড়া। Request Simple হয় যখন:

• Method হলো GET, HEAD বা POST;
• এটা শুধু CORS-safelisted Header বসায়: Accept, Accept-Language, Content-Language, Content-Type, Range;
• Content-Type থাকলে সেটা application/x-www-form-urlencoded, multipart/form-data বা text/plain-এর একটা।

Browser Origin সহ Request পাঠায়, Server উত্তর দেয়, তারপর Browser Access-Control-Allow-Origin মেলায় Page-এর Origin-এর সাথে। এর দুটো ফল মানুষকে অবাক করে:

1. আটকানো Request-ও Server-এ পৌঁছেছে। Handler চলেছে, Database-এ Query হয়েছে, 200 Log হয়েছে। শুধু Page-এর Script ফলটা পায়নি, পেয়েছে একটা সাধারণ TypeError: Failed to fetch; কারণটা থাকে Developer Console-এ, ইচ্ছা করেই Code-এর চোখের আড়ালে।
2. আটকানো থাকলেও একটা Simple POST Data বদলে দিতে পারে। এজন্যই CSRF-এর বিরুদ্ধে CORS কিছুই করে না; তার জন্য লাগে SameSite Cookie, CSRF Token বা Origin যাচাই (Lesson ১.৩, Chapter 35)।

Default অবস্থায় Cross-origin Script শুধু Safelisted Response Header পড়তে পারে (Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma)। অন্যগুলো, যেমন X-Request-ID, ETag বা Location পড়াতে হলে Server সেগুলোর নাম দেয় Access-Control-Expose-Headers-এ।

#Preflight করা Request

বাকি সব (PUT, PATCH বা DELETE; Authorization বা নিজের বানানো Header; Content-Type: application/json) এমন কাজ করতে পারে যা পুরনো কোনো Form পারত না। পুরনো Server অন্য Site থেকে এমন Request আশাই করত না, তাই Browser আগে একটা OPTIONS Request দিয়ে অনুমতি চায়, এটাই Preflight:

OPTIONS /users/42 HTTP/1.1
Host: api.example.com
Origin: https://shop.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: authorization, content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Max-Age: 600
Vary: Origin

Preflight-কে এমন একটা 2xx উত্তর পেতে হবে যেটা Origin, Method আর তালিকার প্রতিটা Header-এর অনুমতি দেয়। তবেই আসল PUT যায়, আর তার Response-এরও নিজস্ব Access-Control-Allow-Origin লাগে। Preflight কখনো Cookie, Authorization বা Body বহন করে না, আর এখান থেকেই আসে CORS-এর সবচেয়ে চেনা Bug: Authentication Middleware CORS Handler-এর আগে চলে আর Preflight-কে 401 দিয়ে ফিরিয়ে দেয়।

Preflight-এ একটা Round Trip খরচ। Access-Control-Max-Age দিলে Browser উত্তরটা Cache করে রাখে, কিন্তু শুধু Origin আর URL ধরে, আর Browser এর একটা সীমাও বাঁধে (Chrome ২ ঘণ্টা, Firefox ২৪ ঘণ্টা; Header না থাকলে ৫ সেকেন্ড)। Path-এ ID থাকা REST API (/users/42, /users/43) প্রতিটা নতুন URL-এর জন্য Preflight দেয়।

Access-Control-Allow-Origin-এ তালিকা রাখা যায় না। কয়েকটা Origin-কে অনুমতি দিতে হলে Server Request-এর Origin নিজের অনুমোদিত তালিকার সাথে মিলিয়ে যেটা মিলল সেটাই ফেরত লেখে, আর সাথে দেয় Vary: Origin, যাতে কোনো Cache এক Origin-এর উত্তর আরেকজনকে না দেয়।

#Credential, আর Cookie-র সাথে * কেন চলে না

Default অবস্থায় Cross-origin Request-এ fetch কোনো Cookie পাঠায় না। Page-কে নিজে বলতে হয় credentials: 'include' (পুরনো XMLHttpRequest-এ withCredentials)। তখন Response পড়া যায় শুধু যদি:

• Access-Control-Allow-Credentials: true থাকে, আর
• Access-Control-Allow-Origin-এ হুবহু Origin-টা লেখা থাকে, কখনো * না। Credential থাকলে Allow-Headers, Allow-Methods আর Expose-Headers-এর *-কেও Wildcard না ধরে আক্ষরিক নাম হিসেবে ধরা হয়।

কারণটা সোজা: * মানে “যেকোনো Site এটা পড়তে পারে”। ব্যবহারকারীর Cookie-র সাথে মিললে এটা যেকোনো Website-কে লগইন করা যেকোনো ব্যবহারকারীর Data পড়তে দিত, তাই নিয়মেই এই জোড়া নিষেধ। সত্যিকারের Public, Credential ছাড়া Data-র জন্য * ঠিক আছে, বরং সেটাই সঠিক: একটা Public API, CDN-এর Font বা Image।

Cookie-র নিজেরও নিয়ম আছে। একই Site-এর API-তে (shop.example.com থেকে api.example.com) SameSite=Lax Cookie যায়। অন্য Site-এর API হলে Cookie-তে লাগবে SameSite=None; Secure, আর যেসব Browser Third-party Cookie আটকায়, তারা তবুও ফেলে দিতে পারে। Web App-এর API নিজের Site-এ, আরও ভালো হয় নিজের Origin-এ রাখার এটা আরেকটা কারণ।

#CORS Browser-এর সুরক্ষা, Server-এর Security না

নোটের Best Practice, কারণ সহ:

• নির্দিষ্ট বিশ্বস্ত Origin-কেই অনুমতি দাও, একটা স্থির তালিকার সাথে পুরো String মিলিয়ে।
• Public না এমন কিছুর জন্য Production-এ * ব্যবহার কোরো না।
• Credential আর Wildcard Origin একসাথে চলে না, নকশাতেই এমন।
• Cookie-ভিত্তিক Authentication-এ CSRF প্রতিরক্ষাও লাগবে, কারণ Simple Request তবুও চলে যায়।
• CORS-কে Firewall ভেবো না।

#চেনা ভুল Configuration

#CORS-কে মাথায় রেখে Design

• পুরোপুরি এড়িয়ে যাও: Reverse Proxy বা CDN-এর Path Rule দিয়ে API-কে একই Origin-এর নিচে দাও (https://shop.example.com/api/… → API Service)। Preflight নেই, CORS Configuration নেই, Cookie First-party।
• স্বাভাবিকভাবে যেখানে সম্ভব Call Simple রাখো: Custom Header ছাড়া GET-এ Preflight লাগে না।
• যুক্তিসঙ্গত Access-Control-Max-Age দাও (যেমন ৬০০–৭২০০ s), আর সম্ভব হলে ব্যস্ত Preflight-ওয়ালা Endpoint-এর Path-এ অনন্য ID না রেখে GET-এ Query Parameter হিসেবে পাঠাও।
• CORS এক জায়গায় Configure করো, API Gateway-তে বা একটা Middleware-এ, যাচাই করা অনুমোদিত তালিকা থেকে।

#System Design-এ Header, Keep-alive, Compression আর CORS

• সবার জন্য খাটে এমন Header Edge-এ বসাও। Security Header, X-Request-ID, X-Forwarded-*-এর পরিচ্ছন্নতা, Compression আর CORS প্রতিটা Service-এ আলাদা না করে CDN, Load Balancer বা API Gateway-তে একবার ঠিকঠাক করা সবচেয়ে সহজ।
• Timeout শিকলের মতো করে মাপো। Client Pool < Load Balancer-এর Idle Timeout < Backend-এর Keep-alive Timeout; আর Deploy-এর সময় Connection: close (বা HTTP/2 GOAWAY) দিয়ে Backend খালি করো।
• সবখানে Connection আবার ব্যবহার করো: Browser থেকে Edge (HTTP/2 বা HTTP/3), Edge থেকে Backend (Upstream Keep-alive), Service থেকে Service (Client Pool), App থেকে Database (Connection Pool, Chapter 18)।
• লেখা Compress করো, Media না, Static File আগেই Brotli দিয়ে Compress করে রাখো, gzip রাখো বিকল্প হিসেবে, Dynamic Response-এ zstd ভেবে দেখো, আর সবসময় Vary: Accept-Encoding পাঠাও।
• Header-কে অবিশ্বস্ত Input ধরো: তোমার Infrastructure নতুন করে না লিখলে X-Forwarded-For, Host আর User-Agent সবই Client-এর লেখা।
• নিজের Web Front-end-এর জন্য CORS-এর চেয়ে একই Origin ভালো; CORS রাখো সত্যিকারের আলাদা ব্যবহারকারীদের জন্য।

#নিজে করে দেখো

# Request আর Response-এর সব Header দেখো (-v), বা শুধু Response Header (-I)
curl -v https://example.com -o /dev/null
curl -sI https://example.com

# Compression চালু কি? Brotli বা gzip চাও, তারপর Content-Encoding আর Vary দেখো
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com | grep -i -E 'content-encoding|vary|content-length'

# একই Resource-এর Compress করা মাপ তুলনা করো
curl -s -o /dev/null -w '%{size_download} bytes\n' https://example.com/
curl -s -o /dev/null -w '%{size_download} bytes\n' -H 'Accept-Encoding: gzip' https://example.com/

# Keep-alive: এক curl-এ দুটো URL দিলে Connection আবার ব্যবহার হয় ("Re-using existing connection")
curl -v https://example.com/ https://example.com/ -o /dev/null -o /dev/null 2>&1 | grep -i -E 're-using|connected to'

# নিজের API-তে একটা CORS Preflight সাজিয়ে পাঠাও, আর Access-Control-* উত্তর পড়ো
curl -i -X OPTIONS https://api.example.com/users/42 \
  -H 'Origin: https://shop.example.com' \
  -H 'Access-Control-Request-Method: PUT' \
  -H 'Access-Control-Request-Headers: authorization, content-type'

# ফেরত লেখার ভুল আছে কি না যাচাই: যে Origin-কে অনুমতি দেওয়ার কথা না, API কি তাকেও দিচ্ছে?
curl -sI https://api.example.com/me -H 'Origin: https://evil.example.net' | grep -i access-control

Browser-এ Developer Tools → Network খোলো, একটা Request-এ Click করে Headers পড়ো: Request আর Response Header, Cross-origin Call-এ Origin Header, আর OPTIONS Preflight আলাদা একটা সারি হিসেবে (Method দিয়ে Filter করো)। তোমার JavaScript যে CORS-এর কারণ দেখতে পায় না, Console সেটা হুবহু দেখায়। HTTP/2 Traffic-এ Pseudo-header দেখা যায় :authority, :method, :path আর :scheme হিসেবে।

#সারসংক্ষেপ

মূল শিক্ষা

• Header হলো Case-insensitive নাম-মানের Metadata: Request, Response আর Representation Header। End-to-end Header প্রাপকের কাছে পৌঁছাতে হবে; Hop-by-hop Header (Connection, Keep-Alive, Transfer-Encoding, TE, Upgrade) প্রতিটা Proxy সরিয়ে ফেলে। HTTP/2 আর HTTP/3-তে ছোট হাতের নাম আর Pseudo-header (:method, :scheme, :authority, :path, :status)।
• জরুরি Header: Host, User-Agent, Accept*, Content-Type, Content-Length, Authorization, Cookie/Set-Cookie, X-Forwarded-For/Forwarded (শুধু তোমার Proxy যা যোগ করে সেটুকু বিশ্বাস করো), X-Request-ID/traceparent, আর Security Header (HSTS, CSP, nosniff, frame-ancestors, Referrer-Policy)। Server-এর Version লুকাও; Header-এর আকারের সীমা মাথায় রাখো (431)।
• Keep-alive: HTTP/1.1-এ Connection নিজে থেকেই টিকে থাকে; Connection: close বন্ধ করে; Keep-Alive: timeout=5, max=100 শুধু ইঙ্গিত, HTTP/2 আর HTTP/3-তে নিষেধ। বারবার ব্যবহারে Handshake, CPU আর Slow Start বাঁচে।
• Idle Timeout: যে Request পাঠায় তাকেই আগে বন্ধ করতে হবে, তাই Backend-এর Timeout Load Balancer-এরটার চেয়ে বেশি (৬৫ s > ৬০ s), নাহলে দৌড় থেকে হঠাৎ হঠাৎ 502। Pool-এ লাগে ঠিকঠাক আকার, Idle Timeout, আয়ু আর শুধু Idempotent Request-এ আবার চেষ্টা। HTTP Keep-alive ≠ TCP Keepalive।
• Compression: Accept-Encoding → Content-Encoding + Vary: Accept-Encoding। gzip ৭০–৮০% ছোট, সবাই বোঝে; Brotli gzip-এর চেয়ে ১৫–২৫% ছোট, Browser শুধু HTTPS-এ দেয়; zstd দ্রুত, ২০২৪ থেকে Chromium আর Firefox-এ। Image, Video, Font বা Archive Compress কোরো না। Dictionary Transport শুধু পার্থক্য পাঠায়; BREACH-এর জন্য লাগে Compression + গোপন তথ্য + ফিরে আসা Input।
• Same-origin Policy: Origin মানে Scheme + Host + Port; Script Cross-origin Response পড়তে পারে না, যদিও Request পাঠাতে আর Resource বসাতে পারে। CORS দিয়ে Server Access-Control-* Header-এ অনুমতি দেয়।
• Simple Request (GET/HEAD/POST, Safelisted Header আর Content Type) সরাসরি যায়, পরে লুকানো হয়; বাকি সবকিছুর আগে Credential ছাড়া একটা OPTIONS Preflight। Max-Age প্রতি URL ধরে Cache করে (Chrome ≤ ২ ঘণ্টা)। Credential-এ লাগে হুবহু Origin, Allow-Credentials: true আর Vary: Origin; কখনো * না।
• CORS Browser-এর সুরক্ষা, Server-এর Security না: curl এটা মানে না, এটা CSRF থামায় না, আর যেকোনো Origin ফেরত লেখা বা null-কে অনুমতি দেওয়া ব্যবহারকারীর Data ফাঁস করে। পারলে API একই Origin থেকে দাও।

নিজেকে যাচাই করো: Header, Keep-alive, Compression আর CORS৩৫টি প্রশ্ন