[eknathdj]

Fixes #422

parse() drops any Vary token that has optional whitespace before its comma:

const { parse } = require('@fastify/cors/vary')
parse('Origin , Accept-Encoding')
// ['accept-encoding']  — 'origin' is dropped

The tokenizer advanced pos past whitespace as it scanned, so when the comma arrived
pos === i and the value before it was never pushed. The same happened to a leading *:
parse('* , foo') returned ['foo'], so createAddFieldnameToVary never saw the wildcard —
which is how the same header also ended up as 'Origin , Accept-Encoding, Origin'.

RFC 9110 §5.6.1 allows OWS around the commas of a list, so that whitespace is not part of the
value.

Change

Drop the whitespace branch and trim each value as it is sliced, skipping the ones that come out
empty:

if (char === ',') {
  const token = header.slice(pos, i).trim()
  if (token !== '') {
    result.push(token)
  }
  pos = i + 1
}

Empty segments behave exactly as before — 'a, , b,c', 'a,,b,c', ',a,b,c' and 'a,b,c,' all
still parse to ['a', 'b', 'c'].

Tests

Added to test/vary.test.js:

• 'a ,b', 'a , b', 'a , , b' and '* , a' parse to the expected values
• a createAddFieldnameToVary case showing 'Origin , Accept-Encoding' is left untouched when
  Origin is added (before this it became 'Origin , Accept-Encoding, Origin')

npm run test:unit passes with 100% coverage.

[SameRainbows]

Thanks for opening this! Note that #423 was opened earlier for the same issue (#422) with a zero-allocation charCodeAt scan that also covers \t (HTAB) per RFC 9110 OWS. Maintainers may prefer consolidating behind #423.