File upload — multipart, stream আর সীমা

১ · একটি ফাইল তারের ওপর দিয়ে কীভাবে যায়

“বাজারঘর”-এর দোকানি রহিমা আপা ইলিশ মাছের একটি ছবি তুলে নতুন পণ্যে যোগ করতে চান। এতক্ষণ আমরা JSON পাঠিয়েছি। JSON হলো লেখা, আর ছবি হলো এলোমেলো byte. একই অনুরোধে পণ্যের নাম (লেখা) আর ছবি (byte) দুটোই যেতে হবে। এই কাজের জন্যই আছে multipart/form-data.

এবার আসল জিনিসটি দেখি। আমরা Edge browser-এ একটি form থেকে ১×১ pixel-এর ৯০ byte PNG পাঠালাম, আর সামনে একটি কাঁচা node:http server বসিয়ে যা এলো হুবহু ধরে রাখলাম। শিরোনামে গেল Content-Type:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQG5LhSqiMKuBnFqf
Content-Length: 394

আর body-র ৩৯৪ byte-এর শুরু আর মাঝের অংশ, বাঁয়ে hex, ডানে যা পড়া যায় (সত্যিকারের run, Edge 156):

0000 2d 2d 2d 2d 2d 2d 57 65 62 4b 69 74 46 6f 72 6d  ------WebKitForm
0010 42 6f 75 6e 64 61 72 79 51 47 35 4c 68 53 71 69  BoundaryQG5LhSqi
0020 4d 4b 75 42 6e 46 71 66 0d 0a 43 6f 6e 74 65 6e  MKuBnFqf..Conten
0030 74 2d 44 69 73 70 6f 73 69 74 69 6f 6e 3a 20 66  t-Disposition: f
0040 6f 72 6d 2d 64 61 74 61 3b 20 6e 61 6d 65 3d 22  orm-data; name="
0050 74 69 74 6c 65 22 0d 0a 0d 0a e0 a6 87 e0 a6 b2  title"..........
0060 e0 a6 bf e0 a6 b6 20 e0 a6 ae e0 a6 be e0 a6 9b  ...... .........
…
00b0 20 66 6f 72 6d 2d 64 61 74 61 3b 20 6e 61 6d 65   form-data; name
00c0 3d 22 70 68 6f 74 6f 22 3b 20 66 69 6c 65 6e 61  ="photo"; filena
00d0 6d 65 3d 22 e0 a6 aa e0 a6 a3 e0 a7 8d e0 a6 af  me="............
00e0 2e 70 6e 67 22 0d 0a 43 6f 6e 74 65 6e 74 2d 54  .png"..Content-T
00f0 79 70 65 3a 20 69 6d 61 67 65 2f 70 6e 67 0d 0a  ype: image/png..
0100 0d 0a 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48  ...PNG........IH
…
0150 00 00 00 00 49 45 4e 44 ae 42 60 82 0d 0a 2d 2d  ....IEND.B`...--
…
0180 75 42 6e 46 71 66 2d 2d 0d 0a                    uBnFqf--..

চারটি জিনিস খেয়াল করুন। প্রতিটি part শুরু হয় -- আর boundary দিয়ে। Header শেষ হয় একটি ফাঁকা লাইনে (0d 0a 0d 0a). e0 a6 87 হলো “ই” অক্ষরের UTF-8 byte, অর্থাৎ শিরোনাম “ইলিশ মাছ” আর ফাইলের নাম “পণ্য.png” দুটোই কাঁচা UTF-8-এ গেছে। আর শেষ boundary-র পরে আরও দুটি হাইফেন (--) মানে পার্সেল শেষ।

ফাইলের byte-এ আছে 0d 0a, যা দেখতে লাইন ভাঙার মতো। তাই multipart ভাঙতে হয় byte হিসেবে, লেখা হিসেবে নয়। নিচের ছোট parser চালিয়ে দেখুন। এটি শেখার মডেল, production-এ নিজে parser লিখবেন না।

// একটি ছোট multipart body হাতে বানাই, তারপর হাতে ভাঙি
const b = '----bazarghar';
const png = Buffer.from([0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]);
const body = Buffer.concat([
  Buffer.from(`--${b}\r\nContent-Disposition: form-data; name="title"\r\n\r\n`),
  Buffer.from('Ilish mach'),
  Buffer.from(`\r\n--${b}\r\nContent-Disposition: form-data; name="photo"; filename="fish.png"\r\n`),
  Buffer.from('Content-Type: image/png\r\n\r\n'),
  png,
  Buffer.from(`\r\n--${b}--\r\n`),
]);

function parse(buf, boundary) {
  const mark = Buffer.from(`--${boundary}`);
  const parts = [];
  let at = buf.indexOf(mark);
  while (at !== -1) {
    const start = at + mark.length;
    if (buf.subarray(start, start + 2).toString() === '--') break;   // শেষ boundary
    const next = buf.indexOf(mark, start);
    const headEnd = buf.indexOf('\r\n\r\n', start);
    const head = buf.subarray(start + 2, headEnd).toString();
    const data = buf.subarray(headEnd + 4, next - 2);    // শেষের \r\n বাদ
    const name = /name="([^"]*)"/.exec(head)[1];
    const file = /filename="([^"]*)"/.exec(head)?.[1];
    parts.push({ name, file, bytes: data.length, data });
    at = next;
  }
  return parts;
}
console.log('body bytes:', body.length);
for (const p of parse(body, b)) {
  console.log(p.name, p.file ?? '(text)', p.bytes, 'bytes', p.file ? p.data.toString('hex') : p.data.toString());
}
console.log('as text:', Buffer.from(png.toString('utf8')).length, 'bytes, real:', png.length);

২ · Browser থেকে পাঠানো — FormData আর progress

Client-এর কাজ সহজ, কিন্তু দুটি ফাঁদ আছে। পর্ব ১২-এ যে FormData দেখেছেন, সেটিই এখানে ফাইলও বহন করে। ধীর মোবাইল নেটওয়ার্কে ব্যবহারকারী progress bar দেখতে চান। fetch()-এ upload-এর অগ্রগতির মানসম্মত event নেই (লেখার সময়ে), তাই এই একটি কাজে পুরোনো XMLHttpRequest এখনও সবচেয়ে সরল পথ।

function uploadPhoto(productId, title, file, onProgress) {
  return new Promise((resolve, reject) => {
    const fd = new FormData();
    fd.append('title', title);
    fd.append('photo', file);

    const xhr = new XMLHttpRequest();
    xhr.upload.addEventListener('progress', (e) => {
      if (e.lengthComputable) onProgress(Math.round(e.loaded / e.total * 100));
    });
    xhr.addEventListener('load', () => {
      if (xhr.status < 300) resolve(JSON.parse(xhr.responseText));
      else reject(new Error(xhr.responseText));
    });
    xhr.addEventListener('error', () => reject(new Error('network')));

    xhr.open('POST', `/api/products/${productId}/image`);
    xhr.send(fd);          // Content-Type নিজে বসাবেন না
  });
}

এই একই ধরনের কোড headless Edge 156-এ চালিয়ে upload গতি ১ MiB/s-এ বেঁধে রাখা হয়েছিল (DevTools protocol), ১৪,০৫,৯১০ byte-এর ছবিতে। সত্যিকারের run, ছোট করে দেখানো:

8%   114688/1406208
15%  212992/1406208
…
93%  1310720/1406208
100% 1406208/1406208
upload load
response 200

total ১৪,০৬,২০৮, অর্থাৎ ফাইলের চেয়ে মাত্র ২৯৮ byte বেশি। Multipart-এর বাড়তি খরচ এখানে মাত্র ০.০২%. একই ছবি JSON-এর ভেতরে Base64 করে পাঠালে হতো ১৮,৭৪,৫৪৮ byte, অর্থাৎ ৩৩% বেশি।

৩ · Express 5-এ multer — চেকপোস্টের সারি

Express-এর express.json() multipart পড়ে না। এই কাজের প্রচলিত package হলো multer, যার ভেতরে কাজ করে busboy নামের parser. লেখার সময়ে সংস্করণ: Express 5.3.0, multer 2.5.0, busboy 1.6.0, sharp 0.35.5, file-type 22.3.0, Node 24.15. npm-এ multer 3-এর একটি alpha আছে; আমরা stable latest নিয়েছি। Multer 1.x-কে npm নিজেই deprecated বলছে, কারণ তার জানা দুর্বলতাগুলো 2.x-এ সারানো।

npm install express@5.3.0 multer@2.5.0 sharp@0.35.5 file-type@22.3.0

এবার সেই পথের কোড। পর্ব ২৯-এ যেমন দেখেছেন, বড় অ্যাপে এই কাজ service স্তরে যায়; এখানে এক ফাইলে রাখা হয়েছে, যাতে পুরো পথ এক নজরে দেখা যায়। অংশ ৫-এর আগে কেবল গঠনটুকু দেখুন। পর্ব ২৬-এর middleware-এর ক্রমটিই এখানে আসল নিরাপত্তা: login-এর আগে multer বসালে অচেনা যে কেউ আপনার disk ভরতে পারত।

const MAX_BYTES = 5 * 1024 * 1024;             // 5 MiB

const upload = multer({
  storage: multer.diskStorage({
    destination: TMP,                          // storage/tmp
    filename: (req, file, cb) => cb(null, randomUUID()),
  }),
  limits: { fileSize: MAX_BYTES, files: 1, fields: 5, parts: 6 },
  defParamCharset: 'utf8',                     // বাংলা ফাইলের নামের জন্য
});

app.post('/api/products/:id/image',
  requireAdmin,                                // সবার আগে
  rejectBigEarly,                              // Content-Length দেখে ফেরত
  upload.single('photo'),                      // তারপর byte পড়া
  async (req, res) => {
    if (!req.file) return res.status(400).json({ error: 'NO_FILE' });
    const tmp = req.file.path;
    try {
      const type = await fileTypeFromFile(tmp);
      if (!type || !ALLOWED.has(type.mime)) {
        return res.status(415).json({ error: 'NOT_AN_IMAGE', detected: type?.mime ?? 'unknown' });
      }
      // sharp দিয়ে 800 আর 200 আকারে .webp বানানো (অংশ ৮)
      res.status(201).json({ /* … */ });
    } finally {
      await rm(tmp, { force: true });          // সফল বা ব্যর্থ, tmp মুছবেই
    }
  });

Express 5-এ async handler-এর rejected promise নিজে থেকেই error middleware-এ যায়, যা পর্ব ২৮-এর central handler ধরবে। upload.single('photo')-কে route-এ বসানো হয়েছে, পুরো অ্যাপে নয়। Multer-এর docs-ও বলে, global middleware হিসেবে বসাবেন না। আর JSON API-র অন্য route-এ ফাইল ঢোকার পথই থাকবে না।

নিচের stepper-এ রহিমা আপার আসল ছবিটি পুরো পথ পার হচ্ছে। সংখ্যাগুলো সত্যিকারের run-এর। ছবিটি কৃত্রিমভাবে বানানো ৪০০০×৩০০০ JPEG.

Memory না disk — multer-এর দুই storage

৪ · Stream, pipeline আর backpressure — মেপে দেখা

Node-এর stream টুকরো (chunk) ধরে ধরে ডেটা নেয়। JavaScript কোর্সের Node পর্বে stream-এর ভিত্তি আছে। এখানে দরকার দুটি জিনিস। Writable stream-এর write() false ফেরালে লেখা থামাতে হয়, আর drain event-এ আবার শুরু করতে হয়। সেই সীমাটির নাম highWaterMark. pipeline() এই থামা-চলা নিজে সামলায়, আর কোনো ধাপে error হলে সব stream বন্ধ করে। পুরোনো .pipe() error-এ বাকি stream বন্ধ করে না, তাই নতুন কোডে pipeline নিন।

const { Readable, Writable, Transform } = require('node:stream');
const { pipeline } = require('node:stream/promises');

const CHUNK = 64 * 1024, CHUNKS = 200;       // মোট 12.5 MiB
const slowDisk = () => new Writable({ highWaterMark: 256 * 1024,
  write(chunk, enc, done) { setImmediate(done); } });   // ধীর ডিস্কের ভান

async function withPipeline() {
  let bytes = 0, peak = 0;
  const disk = slowDisk();
  const counter = new Transform({ transform(chunk, enc, cb) {
    bytes += chunk.length;
    peak = Math.max(peak, disk.writableLength);
    cb(null, chunk);
  } });
  const source = (function* () {
    for (let i = 0; i < CHUNKS; i++) yield Buffer.alloc(CHUNK);
  })();
  await pipeline(Readable.from(source), counter, disk);
  console.log('pipeline : bytes', bytes, 'peak queue', peak);
}

async function ignoreBackpressure() {
  const disk = slowDisk();
  let peak = 0;
  for (let i = 0; i < CHUNKS; i++) {
    disk.write(Buffer.alloc(CHUNK));          // false এলেও থামছে না
    peak = Math.max(peak, disk.writableLength);
  }
  disk.end();
  await new Promise((ok) => disk.on('finish', ok));
  console.log('no pause : bytes', CHUNK * CHUNKS, 'peak queue', peak);
}

withPipeline().then(ignoreBackpressure);

এবার আসল Express server, প্রতি mode-এর জন্য নতুন process. curl দিয়ে ফাইল পাঠিয়ে ৫ ms পরপর process.memoryUsage() মাপা হয়েছে। সত্যিকারের run, Node 24.15, Windows, নিজের মেশিনে:

এখানে একটি অবাক করা সংখ্যা আছে: ২০০ MiB ফাইলে memoryStorage-এর চূড়া ৪০০, ফাইলের দ্বিগুণ। Multer-এর সোর্স খুললেই কারণ পাওয়া যায়: chunks.push(chunk), তারপর Buffer.concat(chunks). জোড়া লাগানোর মুহূর্তে টুকরোগুলো আর নতুন একটানা buffer দুটোই memory-তে থাকে। Disk mode-এর ৬০ MiB-ও জমানো ফাইল নয়; সম্ভবত সেগুলো ব্যবহার শেষ হওয়া chunk, যা garbage collector এখনো সরায়নি। এটি আমাদের ব্যাখ্যা, আলাদা করে মাপা হয়নি। এই সংখ্যাগুলো একটি মেশিনের একটি run, সাধারণ ফল নয়। তবে ধরনটি কোড থেকেই আসে।

সরাসরি busboy-র কোড ছোট, আর এটিই multer-এর ভেতরের চেহারা:

app.post('/up', (req, res, next) => {
  const bb = Busboy({ headers: req.headers, limits: { fileSize: MAX } });
  let info;
  bb.on('file', (name, file) => {
    const to = path.join(TMP, randomUUID());
    info = pipeline(file, createWriteStream(to))
      .then(() => ({ size: statSync(to).size, truncated: file.truncated }));
  });
  bb.on('close', () => info.then((x) => res.json(x)).catch(next));
  req.pipe(bb);
});

৫ · সীমা — আকার, সংখ্যা আর আগাম প্রত্যাখ্যান

সীমা না থাকলে upload route হলো খোলা ট্রাকের ঢোকার পথ। এক অনুরোধেই disk ভরে যেতে পারে, যা DoS-এর সবচেয়ে সহজ রূপ। Multer-এর fileSize-এর default হলো Infinity, মানে সীমা না বসালে কোনো সীমাই নেই।

Multer ব্যবহার না করলেও ধারণাটি একই। নিচের Transform stream গুনে গুনে সীমা পার হলেই error দেয়, আর pipeline সব থামায়:

const { Readable, Writable, Transform } = require('node:stream');
const { pipeline } = require('node:stream/promises');

const MiB = 1024 * 1024;
const LIMIT = 5 * MiB;
let produced = 0, stored = 0;

async function* client() {                     // 50 MiB পাঠাতে চায়
  try {
    for (let i = 0; i < 50; i++) { produced += MiB; yield Buffer.alloc(MiB); }
  } finally {
    console.log('source closed after', produced / MiB, 'MiB');
  }
}

function sizeLimit(max) {
  let seen = 0;
  return new Transform({ transform(chunk, enc, cb) {
    seen += chunk.length;
    if (seen <= max) return cb(null, chunk);
    const e = new Error('file too large');
    e.code = 'LIMIT_FILE_SIZE';
    cb(e);                                     // pipeline সব stream বন্ধ করবে
  } });
}

const disk = new Writable({ write(chunk, enc, done) { stored += chunk.length; done(); } });

pipeline(Readable.from(client()), sizeLimit(LIMIT), disk)
  .then(() => console.log('saved'))
  .catch((err) => {
    console.log('stopped:', err.code);
    console.log('stored', stored / MiB, 'MiB; delete the partial file now');
  });

এবার সত্যিকারের multer-এ ৫০ MiB ফাইল পাঠাই, সীমা ৫ MiB. একটি জিনিস আমরা ধরে নিয়েছিলাম: সীমা পেরোলেই server পড়া থামাবে। মেপে দেখা গেল ঘটনা অন্য।

তাই Content-Length দেখে আগেই ফেরত দেওয়া কাজের। একই ফাইলে তিন route-এর সত্যিকারের ফল, curl থেকে:

$ curl -F photo=@big50.bin .../multer    # শুধু multer-এর সীমা
{"error":"LIMIT_FILE_SIZE"}
[413] uploaded=52429014 t=0.059s
server: seenByServer 52429014, tmpFiles 0

$ curl -F photo=@big50.bin .../early     # আগে Content-Length যাচাই
{"error":"TOO_LARGE"}
[413] uploaded=917504 t=0.002s
server: seenByServer 0, tmpFiles 0

$ curl -F photo=@big50.bin .../busboy    # busboy, truncated যাচাই ছাড়া
{"size":5242880,"truncated":true}
[200] uploaded=52429014 t=0.044s
server: tmpFiles 1

দ্বিতীয়টিতে server কিছুই পড়েনি; curl-এর ৯,১৭,৫০৪ byte শুধু সংযোগের buffer পর্যন্ত গিয়েছিল। Connection: close বসিয়ে সংযোগ বন্ধ করা হয়েছিল। ধীর নেটওয়ার্কে এই পার্থক্য সেকেন্ড নয়, মিনিটের। Localhost-এ তা চোখে পড়ে না, তবে seenByServer সত্যিটা বলে।

সবচেয়ে সস্তা বেড়া আরও সামনে: পর্ব ০২-এর reverse proxy. যেমন nginx-এর client_max_body_size অ্যাপে পৌঁছানোর আগেই বড় অনুরোধ ফেরায়। Proxy-র সীমা অ্যাপের চেয়ে একটু বেশি রাখুন, যাতে সুন্দর JSON error অ্যাপ থেকেই যায়। এই ধরনের কনফিগ পর্ব ৮২-এ।

৬ · ধরন যাচাই — client মিথ্যা বলতে পারে

req.file.mimetype আর ফাইলের extension, দুটোই client-এর লেখা। যে কেউ photo.png নামে যেকোনো কিছু পাঠাতে পারে। তাই একটি fileFilter-এ শুধু mimetype দেখা যাচাই নয়, কেবল ভদ্র client-কে দ্রুত ফেরত পাঠানোর উপায়। আসল উত্তর থাকে ফাইলের ভেতরে। বেশিরভাগ বাইনারি ফরম্যাট শুরুতেই নিজের পরিচয়-byte লেখে, যাকে বলে magic bytes.

// ফাইলের প্রথম কয়েকটি byte দেখে ধরন চেনা
const SIGNATURES = [
  { mime: 'image/png', hex: '89504e470d0a1a0a' },
  { mime: 'image/jpeg', hex: 'ffd8ff' },
  { mime: 'image/gif', hex: '47494638' },
  { mime: 'application/pdf', hex: '25504446' },
];

function sniff(buf) {
  const head = buf.subarray(0, 12).toString('hex');
  if (head.startsWith('52494646') && head.slice(16, 24) === '57454250') return 'image/webp';
  return SIGNATURES.find((s) => head.startsWith(s.hex))?.mime ?? 'unknown';
}

const hex = (s) => Buffer.from(s, 'hex');
const uploads = [
  { name: 'ilish.png', claims: 'image/png', data: hex('89504e470d0a1a0a0000000d49484452') },
  { name: 'dal.jpg', claims: 'image/jpeg', data: hex('ffd8ffe000104a4649460001') },
  { name: 'shell.png', claims: 'image/png', data: Buffer.from('<?php echo 1; ?>') },
  { name: 'page.jpg', claims: 'image/jpeg', data: Buffer.from('<html><script>') },
  { name: 'cv.pdf.jpg', claims: 'image/jpeg', data: Buffer.from('%PDF-1.7 ...') },
  { name: 'photo.txt', claims: 'text/plain', data: hex('52494646aabb000057454250') },
];

const ALLOWED = new Set(['image/png', 'image/jpeg', 'image/webp']);
for (const u of uploads) {
  const real = sniff(u.data);
  const ok = ALLOWED.has(real);
  console.log(`${u.name.padEnd(11)} claims ${u.claims.padEnd(11)} real ${real.padEnd(16)} ${ok ? 'ACCEPT' : 'REJECT'}`);
}

এই কয়েক লাইনের হাতের কোড শেখার জন্য। Production-এ file-type-এর মতো package ভালো, কারণ সে আরও গভীরে দেখে। আমাদের Express server-এ সত্যিকারের run:

$ curl -H 'x-demo-role: admin' .../image -F 'photo=@liar.png;type=image/png'
{"error":"NOT_AN_IMAGE","detected":"unknown"}                  # [415] PHP লেখা, .png নামে
$ ... -F 'photo=@liar.svg;type=image/svg+xml'
{"error":"NOT_AN_IMAGE","detected":"unknown"}                  # [415] script-সহ SVG
$ ... -F 'photo=@sig-only.png;type=image/png'
{"error":"NOT_AN_IMAGE","detected":"unknown"}                  # [415] শুধু ৮ byte PNG সই
$ ... -F 'photo=@real-png-named.txt;type=text/plain'
{"productId":"17","clientName":"real-png-named.txt",
 "clientMime":"text/plain","detected":"image/png", ...}        # [201]
$ ... -F 'photo=@polyglot.png;type=image/png'
{"productId":"17",...,"detected":"image/png","receivedBytes":106,...}   # [201]

শেষ লাইনটি জরুরি। polyglot.png হলো একটি বৈধ PNG, যার শেষে <?php … ?> লেখা জোড়া। এমন দ্বিমুখী ফাইলকে বলে polyglot file. Magic bytes ঠিক, তাই পাস। Magic bytes শুধু শুরুটা দেখে, ফাইলের বাকি অংশ নয়। তাই পরের ধাপে আমরা আসল ফাইল রাখি না, sharp দিয়ে নতুন ছবি বানাই। আমাদের run-এ ইনপুটে <?php ছিল (true), আউটপুট .webp-তে নেই (false).

৭ · নিরাপদ নাম, web root-এর বাইরে, কখনো execute নয়

ফাইলের নাম-ও client-এর লেখা। হাতে multipart বানিয়ে multer-কে কয়েকটি নাম পাঠালাম। সত্যিকারের run, multer 2.5.0:

option            client sent            originalname
default           "পণ্য.png"             "পণà§à¦¯.png"
defParamCharset   "পণ্য.png"             "পণ্য.png"
default           "../../evil.php"       "evil.php"
default           "..\\..\\evil.php"     "evil.php"
preservePath      "../../evil.php"       "../../evil.php"
default           "photo.php.jpg"        "photo.php.jpg"

তিনটি শিক্ষা। প্রথমত, multer-এর default latin1, তাই বাংলা নাম ভেঙে যায়; defParamCharset: 'utf8' লাগে। দ্বিতীয়ত, default অবস্থায় ../ কেটে ফেলা হয়, কিন্তু preservePath চালু করলে পুরো পথ ফেরে। এই path traversal ঠেকানোর একমাত্র পরিষ্কার উপায়: client-এর নাম দিয়ে disk-এর পথ কখনো না বানানো। তৃতীয়ত, photo.php.jpg সব বাধা পার হয়ে যায়।

তাই disk-এর নাম আমরা নিজে দিই: randomUUID() আর আমাদের ঠিক করা extension, যেমন 942c9ccd-…-800.webp. Client-এর নামটি দরকার হলে database-এর একটি কলামে থাকে, শুধু দেখানোর জন্য, আর UI-তে দেখানোর সময় escape হয়। Random নামের আরেকটি লাভ: একই নামে পাঠালে আগের ফাইল ঢেকে যায় না, আর ক্রমিক নম্বরের মতো পরের ফাইল অনুমান করা যায় না।

Web root হলো সেই ফোল্ডার, যার ভেতরের ফাইল server সরাসরি URL-এ দেয়। Upload সেখানে রাখলে যাচাই ছাড়াই ফাইলটি পৃথিবীর সামনে খোলা, তাই storage/ ফোল্ডার public/-এর বাইরে।

৮ · sharp দিয়ে ছবি ছোট করা, আর ফাইল ফেরত দেওয়া

ফোনের ছবি বিশাল, অথচ পণ্যের তালিকায় লাগে ২০০ pixel. sharp হলো libvips-এর ওপর বানানো Node package, যা দ্রুত ছবি কমায়। img.clone() দিয়ে একই ইনপুট থেকে দুটি আকার:

const img = sharp(tmp, { limitInputPixels: 24_000_000 }).autoOrient();
const big = await img.clone()
  .resize({ width: 800, withoutEnlargement: true })
  .webp({ quality: 80 })
  .toFile(path.join(PRODUCTS, `${id}-800.webp`));
const thumb = await img.clone()
  .resize({ width: 200, height: 200, fit: 'cover' })
  .webp({ quality: 75 })
  .toFile(path.join(PRODUCTS, `${id}-200.webp`));

# সত্যিকারের run, sharp 0.35.5, libvips 8.18.7
input jpeg 4000x3000 1405910 bytes; exif 344
800 webp q80 800x600 157696
800 jpeg q80 800x600 144297
800 avif q50 800x600  80497
200 webp q75 200x200  16698
exif after null
keepMetadata exif 344 158066
bomb 12000 12000 144000000 pixels; decoded ~ 432000000 bytes
limit 24M: Input image exceeds pixel limit
default limit: passed, output 1200

১৪,০৫,৯১০ byte থেকে ১,৫৭,৬৯৬ byte, প্রায় ৯ গুণ ছোট। ছবিটি কৃত্রিম noise থেকে বানানো, তাই ফরম্যাটের তুলনা এটি থেকে টানবেন না; আসল ছবিতে ফল আলাদা হবে। আরও দুটি সংখ্যা দেখুন।

• EXIF: ফোনের ছবিতে থাকতে পারে GPS অবস্থান। আমাদের ইনপুটে একটি কাল্পনিক GPS-সহ ৩৪৪ byte EXIF ছিল। আউটপুটে null, কারণ sharp নিজে না বললে metadata রাখে না। দোকানির বাড়ির ঠিকানা ফাঁস হওয়া থেকে এটি বাঁচায়। .keepMetadata() দিলে তা ফিরে আসে (৩৪৪ byte), তাই সেটি ভেবে ব্যবহার করুন। .autoOrient() রাখা হয়েছে, কারণ EXIF মুছে গেলে ফোনের ঘোরানো ছবি উল্টো দেখাতে পারে।
• Decompression bomb: huge-pixels.png মাত্র ৪,৪৬,৪১০ byte, সাদা রঙের ১২০০০×১২০০০ ছবি। ৫ MiB-র সীমায় পাস, magic bytes-এও পাস। কিন্তু ১২০০০ × ১২০০০ × ৩ = ৪৩,২০,০০,০০০ byte, প্রায় ৪১২ MiB হলো খোলা অবস্থার আকার। Sharp-এর default সীমা ২৬,৮৪,০২,৬৮৯ pixel, তাই এটি default-এ পাস করে গেছে (default limit: passed). আমাদের ২৪ megapixel সীমায় আটকেছে, আর Express দিয়েছে 422 TOO_MANY_PIXELS.

ধারণক্ষমতার হিসাব

ধরুন (অনুমান) দিনে ২,০০০ ছবি আসে। প্রতিটিতে আমাদের দুই আকার মিলে ১,৫৭,৬৯৬ + ১৬,৬৯৮ = ১,৭৪,৩৯৪ byte. দিনে ৩৪,৮৭,৮৮,০০০ byte, প্রায় ৩৩৩ MiB; ৩০ দিনে প্রায় ৯.৭৫ GiB. আসল ফাইলও রাখলে দিনে ২,৮১,১৮,২০,০০০ byte, ৩০ দিনে প্রায় ৭৮.৬ GiB. আট গুণ জায়গার সিদ্ধান্ত এটি। আসল ছবি রাখলে পরে নতুন আকার বানানো যায়; না রাখলে সুরক্ষা আর খরচ সহজ।

ফাইল ফেরত দেওয়া — সঠিক header

রাখা যতটা জরুরি, ফেরত দেওয়াও ততটাই। Content-Type ঠিক না থাকলে browser অনুমান করতে পারে; একে বলে content sniffing. আর ডাউনলোড হবে না পাতায় খুলবে, তা ঠিক করে Content-Disposition.

const SAFE_NAME = /^[0-9a-f-]{36}-(800|200)\.webp$/;

app.get('/media/:file', (req, res) => {
  const name = req.params.file;
  if (!SAFE_NAME.test(name)) return res.sendStatus(404);
  res.set('X-Content-Type-Options', 'nosniff');
  res.sendFile(name, { root: PRODUCTS, maxAge: '365d', immutable: true });
});

app.get('/invoices/:id/download', (req, res) => {
  // এখানে মালিকানা যাচাই বসবে (পর্ব ৪৮)
  res.set('X-Content-Type-Options', 'nosniff');
  res.download(invoicePath, 'চালান-১২৩.pdf');
});

$ curl -I .../media/942c9ccd-...-800.webp
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Accept-Ranges: bytes
Cache-Control: public, max-age=31536000, immutable
Content-Type: image/webp
Content-Length: 157696

$ curl -I .../invoices/123/download
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename="?????-???.pdf"; filename*=UTF-8''%E0%A6%9A%E0%A6%BE%E0%A6%B2%E0%A6%BE%E0%A6%A8-%E0%A7%A7%E0%A7%A8%E0%A7%A9.pdf
Content-Type: application/pdf

$ curl -o /dev/null -w '%{http_code}' --path-as-is .../media/..%2f..%2fapp.mjs
404

res.download নিজেই দুটি নাম দিয়েছে: পুরোনো ASCII filename আর UTF-8 filename*. attachment মানে পাতায় খোলা নয়, ডাউনলোড; ব্যবহারকারীর পাঠানো অচেনা ধরনের ফাইল সবসময় এভাবে দিন। immutable নিরাপদ, কারণ random নাম কখনো অন্য ছবিকে বোঝায় না; ছবি বদলালে নামও বদলায়। nosniff browser-কে অনুমান থেকে বিরত রাখে। Regex-টি allowlist: নামের গঠনই না মিললে disk পর্যন্ত যাওয়া হয় না।

৯ · মালিকহীন ফাইল আর object storage

ফাইল আর database দুটি আলাদা জায়গা। একসাথে কখনো পাল্টায় না, তাই মাঝখানে কিছু ভাঙলে মালিকহীন ফাইল জন্মায়। আমাদের server-এ তিনটি পথ পরীক্ষা করলাম:

# ৪ MB ঘোষণা করে ১ MiB পাঠিয়ে client সংযোগ কেটে দিল
tmp after client abort: 0          # multer নিজে মুছেছে
# আধা পথে server process-টি হঠাৎ বন্ধ করা হলো
tmp after crash: 7b30c006-b7bf-425a-8642-8d1148390f5f count=1

Process মরে গেলে finally বা multer কারো চলার সুযোগ নেই, তাই ফাইলটি থেকে যায়। তৃতীয় পথ: ছবি লেখা শেষ, কিন্তু database-এ সারি ঢোকার আগেই কিছু ভাঙল। পণ্য মুছলেও ছবি থেকে যেতে পারে। সমাধান একটি পাহারাদার কাজ, যা নিয়মিত চলবে (পর্ব ৬২-এর background job). নিচের প্রথম run-এ কিছু মোছে না, কেবল দেখায়:

const known = await knownFiles();          // database-এ যে নামগুলো আছে
for (const name of await readdir(DIR)) {
  const full = path.join(DIR, name);
  const s = await stat(full);
  if (known.has(name)) { kept++; continue; }
  if (now - s.mtimeMs < GRACE_MS) { young++; continue; }   // 24 ঘণ্টা
  orphan++; freed += s.size;
  console.log(del ? 'delete' : 'would delete', name, s.size);
  if (del) await rm(full);
}

$ node sweep.mjs
would delete bbb-200.webp 16802
would delete bbb-800.webp 158210
{ kept: 2, young: 1, orphan: 2, freed: 175012 }
$ node sweep.mjs --delete
delete bbb-200.webp 16802
delete bbb-800.webp 158210
{ kept: 2, young: 1, orphan: 2, freed: 175012 }

young ফাইলটি মালিকহীন, কিন্তু বয়স ২৪ ঘণ্টার কম, তাই বেঁচে গেছে। এই ছাড়ের সময় না থাকলে পাহারাদার চলমান upload-এর ফাইলও মুছে ফেলত, কারণ তার database সারি এখনো তৈরি হয়নি। ক্রমের নিয়ম: আগে ফাইল, পরে database সারি। মোছার সময় উল্টো: আগে সারি, পরে ফাইল। ভাঙলে তখন বাড়তি ফাইল থাকে, ভাঙা লিংক নয়, আর বাড়তি ফাইল পাহারাদার ধরে ফেলবে।

Object storage আর presigned URL

একটি server-এর disk-এ ফাইল রাখলে দুটি সমস্যা। Server দুটি হলে একটির ফাইল অন্যটি পায় না। আর সব byte অ্যাপের মধ্য দিয়ে গেলে বড় ফাইলে সংযোগ আটকে থাকে। বড় অ্যাপ তাই ফাইল রাখে object storage-এ, S3-ধাঁচের API-তে, যা অনেক সেবা ও নিজে চালানোর সফটওয়্যারে পাওয়া যায়। আর ব্রাউজারকে দেয় একটি presigned URL: সই করা, সময়-বাঁধা, একটি নির্দিষ্ট কাজের টিকিট। সেবাগুলোর তুলনা এখানে নয়; পুরো নকশা পর্ব ৬৪-এ, চালানোর দিক পর্ব ৮২ আর Cloud & DevOps কোর্সে, ভেতরের নকশা System Design কোর্সে.

সই বানাতে নেটওয়ার্ক লাগে না, শুধু গোপন চাবি। সম্পূর্ণ নকল key আর কাল্পনিক ঠিকানায় @aws-sdk/client-s3 3.1161.0 চালিয়ে এই URL পেলাম (কোথাও পাঠানো হয়নি, সত্যিকারের কোনো সেবা জড়িত নয়):

https://storage.example.test/bazarghar-media/incoming/3f9c1b7e.jpg?
  X-Amz-Algorithm=AWS4-HMAC-SHA256
  &X-Amz-Content-Sha256=UNSIGNED-PAYLOAD
  &X-Amz-Credential=EXAMPLEKEY%2F20261101%2Fap-south-1%2Fs3%2Faws4_request
  &X-Amz-Date=20261101T163742Z
  &X-Amz-Expires=300
  &X-Amz-Signature=0f75a0ba791cae8b0cbf7509d280ea549a15171aea2d858ee68106d8e4609376
  &X-Amz-SignedHeaders=content-type%3Bhost
  &x-id=PutObject

X-Amz-Expires=300 মানে ৫ মিনিট। একটি ফাঁদ ধরা পড়ল: শুধু ContentType দিলে প্রথম run-এ SignedHeaders=host এসেছিল, অর্থাৎ ধরনটি সইয়ে ঢোকেনি। signableHeaders: new Set(['content-type']) দেওয়ার পরই ওপরের ফল এলো। আর UNSIGNED-PAYLOAD মনে করিয়ে দেয়, সই ফাইলের ভেতরের byte যাচাই করে না।

এই stepper ধারণা বোঝানোর জন্য; এখানে আসল object store-এ upload চালানো হয়নি, কেবল ওপরের URL-টি বানানো হয়েছে। ট্রেড-অফ আছে: সরাসরি upload-এ অ্যাপ হালকা হয়, তবে যাচাই দেরিতে হয়, CORS কনফিগ লাগে, আর নকশা জটিল হয়। ছোট দোকানে একটি server-এর disk দিয়েই শুরু করা ঠিক সিদ্ধান্ত হতে পারে, যদি backup থাকে।

১০ · AI-এর যুগে file upload

Upload কোড AI খুব দ্রুত লেখে, আর সেই কোড সহজ পরীক্ষায় চলেও। সমস্যা হলো, ছবি পাঠালে চলা মানেই অন্য কিছু পাঠালে আটকানো নয়। আর ফাঁকগুলো সবই ভুল ইনপুটেই ধরা পড়ে।

AI-এর লেখা upload কোডের চেকলিস্ট

• Package আর option, প্রতিটি সেই version-এর docs-এ আছে কি না নিজে দেখেছি; অচেনা package থাকলে npm-এ খুঁজেছি
• Limit ভেঙে, ভুয়া ফাইল দিয়ে আর login ছাড়া পাঠিয়ে সঠিক 4xx পেয়েছি
• ব্যর্থ অনুরোধের পরে tmp ফোল্ডার গুনে দেখেছি, ফাঁকা আছে
• Upload করা ফাইলের সরাসরি URL অনুমান করে খুলতে চেষ্টা করেছি, পাইনি
• Key, secret বা token কোডে বা client bundle-এ নেই; AI-কে আসল secret পেস্ট করিনি
• catch error গিলে ফেলছে না; diff পড়েছি আর এই ব্যর্থ ঘটনাগুলোর test লিখেছি