Need for a mechanism to detect supported conditions and sources in the SW Static Routing API

[yoshisatoyanagisawa]

The Service Worker Static Routing API defines routing rules using a dictionary. This design presents a potential issue for developers. If a rule includes a condition that the user agent does not recognize or support, it may be silently ignored rather than causing a syntax error. This could lead to the rule being applied in unintended situations, creating unpredictable behavior that is difficult to debug.

For example, if a developer includes a new or experimental condition in a rule, the rule might be partially applied on browsers that don't support that specific condition, effectively ignoring a critical piece of the intended logic. This behavior makes feature detection and graceful degradation difficult to implement reliably.

To address this, I propose the introduction of a mechanism to allow developers to verify which conditions and sources are supported by the user agent. This could be achieved in a few ways:

1. An API to Enumerate Supported Features: Introduce a method that returns a list of supported condition and source values. For example:

const capabilities = await event.getStaticRoutingCapabilities();
console.log(capabilities.supportedConditions); // ['urlPattern', 'requestMode', ...]
console.log(capabilities.supportedSources); // ['fetch', 'cache', ...]

2. An API to Validate a Rule: Provide a method that allows developers to check if a set of conditions or sources is supported before adding the rule. This would enable proactive validation.

// Returns true if all specified condition keys are supported by the UA.
const areConditionsSupported = await event.supportsConditions([
  'requestMethod', 
  'or', 
]);

if (areConditionsSupported) {
  // All conditions are supported, so we can safely add the rule.
  await event.addRoutes({
    condition: { 
      or: [
        { requestMethod: "GET" },
      ]
    },
    source: "network"
  });
} else {
  // A condition is not supported. Use fallback logic.
  console.log('A required routing condition is not supported. Using a simpler rule.');
}

3. A "Required" or "Mandatory" Field in addRoutes(): Add an option to specify that certain conditions are essential for a rule. If a mandatory condition is not supported by the user agent, the addRoutes() call would reject, rather than silently ignoring the condition.

await event.addRoutes([{
  condition: {
    or: [
      { requestMethod: "GET" }
    ]
  },
  source: "network"
  // This would cause the call to fail if `requestMethod` is not supported.
  requiredConditions: ["requestMethod"]
}]);

This topic has been previously discussed in WICG/service-worker-static-routing-api#28.

[asutherland]

whatwg/webidl#107 seems to be the canonical issue on this type of problem with the first comment ("OP") describing a(n awkward) mechanism where getters are used to detect what the dictionary population does. While the OP there does not handle detecting valid enum values, they are discussed in the issue as desired. The issue is definitely worth reading in its entirety (especially if replying since the issue did start to suffer from people missing things).

I think it would definitely be desirable to try and move that issue forward before going too far down the road of doing something custom here.

[yoshisatoyanagisawa]

Sorry for the lag to update the issue, but upon the TPAC, @youennf has suggested to go with the getter hack as a short term solution, and goes into the IDL approach as a long term solution.

I doubt the long term solution comes soon, but at the same time, I think the API should be made upon the real needs. I basically follow the direction, and will leave this as-is except a request from web developers.

[youennf]

FWIW, the getter hack short term solution (for newly introduced properties) would be something like:

function isNewPropertySupported(propertyName) {
  const newPropertyError = new Error('newPropertyError');
  const routeWithNewProperty = { };
  Object.defineProperty(routeWithNewProperty, propertyName, {
    get: function() { throw newPropertyError; }
  });
  const throwingRoute = {
    get urlPattern() { throw new Error('expectedError'); }
  };
  return installEvent.addRoutes([routeWithNewProperty, throwingRoute]).catch(e => {
    return e === newPropertyError;
  });
}

[yoshisatoyanagisawa]

Thanks for the reply. To be clear, actual code to check the supported condition might be:

function isNewPropertySupported(installEvent, propertyName) {
  const newPropertyError = new Error('newPropertyError');
  const conditionWithNewProperty = { };
  Object.defineProperty(conditionWithNewProperty, propertyName, {
    get: function() { throw newPropertyError; }
  });
  const throwingCondition = {
    get urlPattern() { throw new Error('expectedError'); }
  };
  const routes = [
    {
      condition: conditionWithNewProperty,
      source: "network"
    },
    {
      condition: throwingCondition,
      source: "network"
    }];
  return installEvent.addRoutes(routes).catch(e => {
    return e === newPropertyError;
  });
}

Yeah, we assume the urlPattern condition and the network source are always supported.