Aligning the session duration with a configurable value rather than the hard-coded 7 days addresses the issue raised. However, there are a couple of things worth reviewing:

• For noExpiryNano, it may be safer to use math.MaxInt64 or explicitly type the const as an int64 to avoid any potential shift/overflow edge cases with 1<<63.
• When allowing a cookie to effectively never expire (using a large Max-Age), it may be worth noting that there are potential security implications if a session cookie is stolen.
• For SessionCookiePath, prefixing with "/" is good. It may also be worth trimming whitespace or guarding against unexpected values.

It would also help to include a short “Changes Made” or brief testing note instead of just “Not tested”, even if only manual verification steps.

Aligning the session duration with a configurable value rather than the hard-coded 7 days addresses the issue raised. However, there are a couple of things worth reviewing:

* For noExpiryNano, it may be safer to use math.MaxInt64 or explicitly type the const as an int64 to avoid any potential shift/overflow edge cases with 1<<63.

* When allowing a cookie to effectively never expire (using a large Max-Age), it may be worth noting that there are potential security implications if a session cookie is stolen.

* For SessionCookiePath, prefixing with "/" is good. It may also be worth trimming whitespace or guarding against unexpected values.

It would also help to include a short “Changes Made” or brief testing note instead of just “Not tested”, even if only manual verification steps.

Updated

LGTM.

Thanks for addressing the typing change and path normalisation, and for adding tests around no-expiry and cookie path handling

@steadytao are you able to merge this now?

@vvaswani I do not have maintainer access to SyncThing, I am only a contributor and Jakob is currently busy and has been for some time. Please give him some time to review your PR

• @calmh Gentle ping