fix: Keep lightweight request even if accessing method, url or headers

[usualoma]

#269

What is this?

Stop generating heavy global.Request just by accessing req.headers.

This eliminates the memory consumption that until now was caused by simply applying the simple middleware called cors(), which generated a global.Request and was hard to free up until GC was executed.

Cases not resolved

In situations where we accept a lot of lightweight POST requests, this pull request will not improve on memory usage.

[usualoma]

@yusukebe

It won't solve every situation, but I believe it will improve things for very simple apps like the one below (which involves accessing headers).

https://github.com/yusukebe/hono-nodejs-adapter-memory-leak

Shall we add this?

[yusukebe]

LGTM!

[yusukebe]

Using new Headers instead of creating Request is nice.

It's just an idea, maybe overwork, we should not add it in this PR, but is creating LightweightHeaders a good idea?

class LightweightHeaders {
  constructor(rawHeaders) {} // or constructor(headerRecord)

  get(name) {
    // find the value from rawHeaders or headerRecord
  }

  has(name) {
    // find the value from rawHeaders or headerRecord
  }

  set(name, value) {
    this.toHeaders.set(name, value)
  }

  toHeaders() {
    const headers = new Headers(this.entries())
    // cache headers
    return headers
  }
}

It's for readonly, so it returns the value by .get() from rawHeaders or headerRecord, and if accessing .set(), do new Headers().

Anyway, we can merge this PR.

[usualoma]

LightweightHeaders is a great idea! However, I'm concerned that using it like fetch(url, {headers: c.req.raw.headers}) would introduce more compatibility issues to worry about, making it not worth the maintenance cost.

[yusukebe]

@usualoma

Shall we add this?

Yes! Thank you!

[yusukebe]

I wondered if we should label fix, feat, or others, but I labeled it fix.

[usualoma]

@yusukebe

Thank you!

I wondered if we should label fix, feat, or others, but I labeled it fix.