fix: accept a negative Set-Cookie Max-Age attribute

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.

[arshsmith1]

This relates to...

N/A

Rationale

parseUnparsedAttributes in lib/web/cookies/parse.js validates the Max-Age attribute-value with /^\d+$/, applied to the whole value rather than to the remainder after the sign. Any negative Max-Age therefore fails the check and the attribute is dropped from the parsed cookie:

getSetCookies(newHeaders({'set-cookie': 'id=a; Max-Age=-1'}))// [{ name: 'id', value: 'a' }]// should be: [{ name: 'id', value: 'a', maxAge: -1 }]

RFC 6265bis section 5.6.2 is explicit that a leading - is allowed:

If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av.

If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av.

If delta-seconds is less than or equal to zero (0), let expiry-time be the earliest representable date and time.

The step-1 check at line 193 already accepts - as a first character, and the last step above only has meaning if negative values reach it, so the intent in the surrounding code is the spec behaviour. Max-Age=-1 is the usual way a server expires a cookie, and today that signal is silently lost by getSetCookies().

The generation side is deliberately left alone: validateCookieMaxAge still rejects negatives, which matches the max-age-av = "Max-Age=" non-zero-digit *DIGIT grammar a server must emit. Parsing is permissive, serialising stays strict.

Changes

Relax the digit check to /^-?\d+$/ so a single leading sign is accepted and a non-DIGIT remainder is still ignored. Max-Age=-, --1, -1a, +1 and the empty value all stay ignored, and positive values are unchanged.

Features

N/A

Bug Fixes

• Set-Cookie: ...; Max-Age=-1 now parses to maxAge: -1 instead of dropping the attribute.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Documented
• Review ready
• In review
• Merge ready

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.34%. Comparing base (1383989) to head (55df30d).
⚠️ Report is 50 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5571 +/- ##
==========================================
- Coverage 93.47% 93.34% -0.13% 
==========================================
Files 110 110 Lines 37560 38778 +1218 ==========================================
+ Hits 35108 36197 +1089 - Misses 2452 2581 +129 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tsctx]

Please make the following changes to ensure closer adherence to the specifications.

Suggested change

	if(!/^\d+$/.test(attributeValue)){
	if(/[^\d]/.test(attributeValue.slice(1))){

[arshsmith1]

Good call, that reads much closer to the spec. I took the remainder check as suggested and also tightened step 1 to the current 6265bis wording (a "-" followed by a DIGIT). Without that, slice(1) lets a bare Max-Age=- and an empty value slip past step 2 and parse to NaN/0, so validating the sign up front keeps them ignored while step 2 stays the clean remainder check you wanted. The existing edge cases and the -1 case all still pass. Pushed in 4403160.

[tsctx]

Could you please revert this change? This comment block is intended to preserve the exact wording from the specification.

[arshsmith1]

Reverted, the comment block is back to the original spec wording. The code still does the sign-followed-by-digit check but the comment stays verbatim.