🐛 Bug Report — Inconsistent etag parsing error in R2 bindings api

[flakey5]

Background

• There is a worker in development to serve Node.js downloads (https://github.com/nodejs/release-cloudflare-worker).
• We fetch the assets from R2 via the R2 bindings api.
• We directly pass in the request.headers object into the R2Object.get()'s onlyIf and range options.

Issue

Last week, we started seeing a client pass in conditional headers that wrapped the etags in quotes (e.g. "W/"5a49a0bd-39326"" or ""asd123""). Sometimes this error is thrown, other times it isn't.

Repro

// worker.ts
interface Env {
  BUCKET: R2_BUCKET;
}

export default {
  async fetch(request: Request, env: Env) {
    await env.BUCKET.get('some-file', { onlyIf: request.headers, range: request.headers }); 
  }
}

// client.ts
for (let i = 0; i < 100; i++) {
  fetch('https://the-worker.com', {
    headers: {
      'If-None-Match': '"W/"5a49a0bd-39326""'
    }
  })
}

The Question

Is that etag format supported or something we need to validate before passing in?

[jasnell]

Spoke with @flakey5 about this a bit offline but posting here also... the etag "W/"5a49a0bd-39326"" is not valid syntax. What I would recommend for now is validating the input and ignoring invalid etags when making the request to r2. That should avoid the issue. That said, if r2 is having a problem with these then we should very likely have r2 also ignore invalidly formatted etag inputs... or at least handle them more gracefully.

[flakey5]

Fwiw last time I checked the R2 bindings will consistently throw an error for some etag errors (off the top of my head I remember unquoted etags) but the error messages were very vague and took a bit to figure out what the actual problem was

[harshal317]

As y'all noticed these are in fact invalid with the quotations. The error there isn't very helpful, we ought to improve the messaging. I think it'd make sense to remove this header parsing out of workerd and into R2s API implementation.