The fixed-layout Request

Today a header value is a plain string sitting in a map. A much later chapter rebuilds that storage completely - header values stop being strings and become offset ranges into the arrival buffer, materialized only when someone actually reads them, and that is what finally makes the parser live up to its title. That rebuild has to be invisible to every caller. The only way to guarantee this is to make callers go through methods, and never let them poke at the storage directly.

An accessor is a method used for reading stored data. Request provides header(name), headerAll(name), and the headers getter. A getter runs when code reads a property, so req.headers can compute and return a value without being called like req.headers(). Callers use these accessors instead of reading the internal map, so a later storage change can keep the same public behaviour.

The constructor declares nine fields - every single one of them, in a fixed textual order. Here is what each one holds.

method     ""       the request method, e.g. "GET"          (from the request line)
  url        ""       the raw request-target, "/users?id=7"   (from the request line)
  path       ""       the target before the "?", "/users"     (the router matches this)
  rawQuery   ""       the target after the "?", "id=7" or ""   (a later chapter parses it)
  version    "1.1"    "1.1" or "1.0", the digits after HTTP/   (keep-alive reads this)
  socket     null     the connection this request arrived on
  app        null     the application that will dispatch it
  _buf       null     the backing buffer the request's bytes live in
  _headerMap null     the header store; the parser fills it in

Five fields store the request-line strings. socket and app are null today because the teaching server receives the socket directly and no application object exists yet. Still, they belong to the fixed property layout. _buf holds the buffer containing the request bytes. _headerMap stays null till the parser starts reading fields.

V8 records an internal property layout from the names and order of properties added to an object. V8 documentation and diagnostics call this layout a hidden class or map. Objects with the same layout can share the same optimized property-access code. A hot path is code that runs for every request, so small per-request costs keep on repeating. Later chapters insert new fields at reserved positions, and they don't reorder these nine.

The accessors are small ones, but their contracts are exact.

• header(name) returns a string or undefined. It lowercases the name you pass, so header("Host"), header("host") and header("HOST") all hit the same key. If the field repeated and the slot holds a list, it returns the first value.
• headerAll(name) returns a string[], and always a fresh array, never your internal storage. One element for a single value, a copy of the list for a repeated field, and an empty array when the header is absent. Returning a fresh array means a caller can never mutate what the parser stored.
• headers is a getter which returns a null-prototype object of all the headers. It is the documented slow path, meant for dumping everything while you're poking around. For a single lookup, prefer header().

All three must be null-safe. Before the parser assigns _headerMap, it is null, and calling any accessor should not throw.

One design question is worth answering out loud here. When a field repeats, why does header() return the first value and not the RFC's comma-joined form? Two reasons. First, it matches what the later offset-scan rewrite does (it returns on the first match), so this accessor's behaviour stays identical across that seam. A comma-join today would silently become a behaviour change later, or it would force that chapter to allocate exactly the joined strings it exists to avoid. Second, nothing is lost - headerAll(name) gives you every value, so a caller who wants the joined form can join the list themselves.

The header map is Object.create(null) and not a plain {}. A plain object inherits properties from Object.prototype through its prototype chain. The prototype chain is the sequence of objects JavaScript searches when an own property is absent. Names like __proto__, constructor and toString already have behaviour on that chain. A client controls its own header names, so those names must get stored as ordinary data. Changing an object's prototype through untrusted keys is called prototype pollution.

A null-prototype object has no inherited property chain at all. Every key, including __proto__, is an ordinary own property. The series uses null-prototype objects whenever client-controlled names become object keys.