treat malformed s-maxage as absent in shared-cache auth check

[dxbjavid]

A shared cache must not store a response to a request that carried an Authorization header unless the response permits it through s-maxage, must-revalidate or public (RFC 9111 3.5). The guard treats any s-maxage as qualifying, but a malformed value like s-maxage=foo is parsed as 0 rather than -1, so it looks present and the authenticated response is stored in the shared cache and can later be handed to other clients on a revalidated hit. This tracks whether a valid s-maxage was actually supplied and uses that in the check, so a malformed directive is treated as absent as the spec requires; the numeric value is left unchanged so freshness behaviour is not affected.

[ok2c]

@dxbjavid Why not making it even simpler?

public static long deltaSeconds(final String s) {
    if (TextUtils.isEmpty(s)) {
        return -1;
    }
    try {
        long ageValue = Long.parseLong(s);
        if (ageValue < 0) {
            ageValue = -1;  // Handle negative age values as invalid
        } else if (ageValue > Integer.MAX_VALUE) {
            ageValue = MAX_AGE.toSeconds();
        }
        return ageValue;
    } catch (final NumberFormatException ignore) {
        return -Integer.MAX_VALUE;
    }
}

[ok2c]

@dxbjavid In fact my original implementation of #deltaSeconds is wrong. It should be returning -1, not 0 if the value cannot be parsed.

[dxbjavid]

agreed, that's the cleaner root cause. i've pulled it into deltaSeconds so an unparseable value now returns -1 instead of 0, which means a malformed s-maxage reads as absent everywhere it's used and the original shared-cache auth check catches it with no extra plumbing. that let me drop the sentinel and revert the parser and policy changes entirely, so the fix is now just the one line in deltaSeconds plus the two tests that were asserting the old 0. full cache suite is green.

[ok2c]

@dxbjavid cherry-picked to 5.6.x

[dxbjavid]

TY!