Independent Node.js Headers module

[Ethan-Arrowood]

#32 has sparked an interesting discussion about Headers in Node.js

I'm very open to the idea of a standalone headers core module for Node.js. We could contribute this directly to Node core or it can exist similar to nodejs/undici repo for now. This standardization would be very helpful for libraries such as undici, undici-fetch, and many others.

WDYT?

[Ethan-Arrowood]

@mcollina @timdp FYI let's discuss headers stuff more here

[Ethan-Arrowood]

One important aspect of a headers module would be that it standardizes how headers are handled across node ecosystem.

Any sort of Headers class will never beat the performance of just a regular object, but I think we could create something as-performant-as-possible and then also provide utilities that allow for even faster use cases.

One such example I'm thinking of is if a module wants to manage headers using an array. We could provide utilities that operate specifically for arrays; or we at least provide the core APIs necessary to do so. Normalization, validation, joining, etc.

[ronag]

I was more thinking of a 1D array rather than 2D. You kind of lose the efficiency with a 2D array.

[ronag]

We would need some way to access the non-sorted raw array or the performance boost is lost.

[Ethan-Arrowood]

we can export the symbol so those that know what they are doing can get the direct access

[Ethan-Arrowood]

Im working on a 1D version now. Sorting is much more difficult.

[Ethan-Arrowood]

class ArrayHeaders {
  constructor (init) {
    this[kHeaders] = []

    if (init && typeof init === 'object') {
      fill(this, init)
    }
  }

  append (name, value) {
    const [normalizedName, normalizedValue] = normalizeAndValidateHeaderValue(name, value)

    let isNewEntry = true
    for (var i = 0; i < this[kHeaders].length; i+=2) {
      if (normalizedName === this[kHeaders][i]) {
        this[kHeaders][i+1] += `, ${normalizedValue}`
        isNewEntry = false
        break
      }
    }

    if (isNewEntry) {
      this[kHeaders].push(normalizedName)
      this[kHeaders].push(normalizedValue)
    }
  }

  delete (name) {
    const normalizedName = normalizeAndValidateHeaderName(name)

    for (var i = 0; i < this[kHeaders].length; i+=2) {
      if (normalizedName === this[kHeaders][i]) {
        this[kHeaders].splice(i, 2)
        break
      }
    }
  }

  get (name) {
    const normalizedName = normalizeAndValidateHeaderName(name)

    for (var i = 0; i < this[kHeaders].length; i+=2) {
      if (normalizedName === this[kHeaders][i]) {
        return this[kHeaders][i+1]
      }
    }

    return null
  }

  has (name) {
    const normalizedName = normalizeAndValidateHeaderName(name)

    for (var i = 0; i < this[kHeaders].length; i+=2) {
      if (normalizedName === this[kHeaders][i]) {
        return true
      }
    }

    return false
  }

  set (name, value) {
    const [normalizedName, normalizedValue] = normalizeAndValidateHeaderValue(name, value)

    let isNewEntry = true
    for (var i = 0; i < this[kHeaders].length; i+=2) {
      if (normalizedName === this[kHeaders][i]) {
        this[kHeaders][i+1] = normalizedValue
        isNewEntry = false
        break
      }
    }

    if (isNewEntry) {
      this[kHeaders].push(normalizedName)
      this[kHeaders].push(normalizedValue)
    }
  }

  * keys () {
    for (const header of this) {
      yield header[0]
    }
  }

  * values () {
    for (const header of this) {
      yield header[1]
    }
  }

  * entries () {
    yield * this
  }

  forEach (callback, thisArg) {
    this[kHeaders] = sort(this[kHeaders])
    for (let i = 0; i < this[kHeaders].length; i+=2) {
      callback.call(thisArg, this[kHeaders][i+1], this[kHeaders][i], this)
    }
  }

  * [Symbol.iterator] () {
    this[kHeaders] = sort(this[kHeaders])
    for (let i = 0; i < this[kHeaders].length; i+=2) {
      yield [this[kHeaders][i], this[kHeaders][i+1]]
    }
  }
}

function sort (headers) {
  const names = []
  for (let i = 0; i < headers.length; i+=2) {
    names.push(headers[i])
  }
  names.sort()
  const sorted = []
  for (const name of names) {
    sorted.push(name)
    sorted.push(headers[headers.indexOf(name) + 1])
  }
  return sorted
}

Sorting algorithm is not optimized at all; literally just wrote the first thing that came to mind. I haven't attempted to benchmark any of this yet, but at least this is using a single internal array

[Ethan-Arrowood]

Writing an implementation using V8 internals or compiling to WASM is a great idea. Llhttp has proven that is a great solution for generally non-performant Web compatibility things

[timdp]

Would it though? I expect overhead from serialization, fiddling with shared memory, and a huge barrier to entry from people looking to contribute. All to shave off a millisecond of processing for an HTTP client?

[mcollina]

I have no idea if it would be worth it. The majority of the costs in managing headers come from the case insensitivity and all the arrays/objects needed to support that. If we could have a data structure where we put headers in and we get a string ready to be sent on the wire out... it might be well worth it. Some research on fast data structures might be necessary.

Regarding the 1ms comment, I'll try to explain my point of view. Let's consider a deployment where we have 1 CPU and we would like to handle 1000 HTTP req/sec. The max CPU processing time for each request is 1ms. If our target became 10k req/sec, then our budget is 0.1ms.

The goal for a utility library to make HTTP requests is to not be the bottleneck - i.e. optimizations in that library are unlikely to be measurable by the users. This usually means that the CPU time spent in frameworks and libraries must be one or two order of lower than the time spent in the business logic.

[timdp]

I'm not advocating that we dismiss the idea without further research but let me illustrate our use case.

For many years, we've been operating a proxy service that pulls in XML over HTTP, rewrites it, and sends it back to the client. Engineering for performance has been a challenge.

Obviously, we've had to optimize the heck out of the XML processing. When we got that under control, we were able to focus more on HTTP requests.

Frankly, based on the profiler, header processing was never on our radar. Instead, we've been investing our time in things like DNS caching, pipelining, and h2 support (and hopefully QUIC at some point). All of those are fairly critical, yet still tricky to get right today. If it were up to me, I'd make sure a new HTTP client was able to address those needs, more than trying to save nanoseconds on headers.

I realize that a) I'm biased, b) these are nontrivial concerns, and c) they're not mutually exclusive. However, in reality, I do think priorities are going to matter a lot.

[mcollina]

The nicest thing about Open Source is that everybody can volunteer to work on what matters to them. Nobody is preventing you to contribute wherever you see fit and a maintainer is happy to land your changes (or give you the commit bit). This is definitely true on Undici and Node.js.

All those things you mentioned are important, there is really a lot to work on!

[timdp]

That's one of the reasons why I started to contribute to undici-fetch. But it doesn't mean that premature optimization is a good idea. 🙂

[Ethan-Arrowood]

Copying pasting relevant comment thread from a recent Headers related PR that has some additional ideas: #36 (comment)

[Ethan-Arrowood]

nodejs/node#38986