Evaluate headers only after status and content type, match patterns as ECMA-262 (dpp-criteria 4fcfe5c)

[fabianekc]

Adapts resolve checks to dpp-criteria 4fcfe5c (PR #4), sections "Order of evaluation within a request" and "Regular expressions" in CRITERIA-FORMAT.md.

Changes

• Order of evaluation: for the first resolve request and each of further_requests, status and content_type are evaluated first. Header assertions are evaluated only if both hold; otherwise they give no message of their own. The JSON object check that dpplint applies to content_type: application/json counts as part of the content type. applies_if is unchanged.
• matches in header assertions: ECMA-262 without flags, searched anywhere in the value, case-sensitive. ^ and $ anchor the whole value, also if it contains a line break.
  • New EcmaRegexp parses the pattern as ECMA-262 and translates it into an equivalent Ruby Regexp. It includes the Annex B rules that apply without flags: \A is the letter A, a lone { is a literal.
  • It covers the differences that change results: ^/$ (line anchors in Ruby), . and line terminators, \s, \b, [a&&b], [[a], a{,2}, a{2}?.
• Invalid patterns: a pattern that is not valid ECMA-262 skips the criterion with a reason, checked before any request. So does a valid pattern that uses features outside the portable subset (lookaround, named groups, backreferences, legacy octal escapes, \k, lone surrogates).
• Known deviation: characters outside the Basic Multilingual Plane count as one character here and as two UTF-16 code units in ECMA-262. This matters only for ., character classes and quantifiers applied to such a character.
• Not evaluated in resolve: json and body_equals_step. A criterion that uses them is still skipped. No resolve criterion in dpp-criteria uses them at present.

Tests

• 136 runs, 385 assertions, 0 failures, 0 errors, 0 skips in the image built with ./build.sh (dpp-criteria 4fcfe5c).
• Order of evaluation: wrong status, wrong content type, both wrong, and both right, for the first request and for further requests.
• Patterns:
  • searched without anchoring;
  • ^ and $ on values with a line break;
  • case sensitivity;
  • Annex B literals;
  • invalid and non-portable patterns give skipped with a reason, without a request.
• Cross-checked against JavaScript (new RegExp(p).test(v)) for 55 patterns × 52 values. The only difference is the BMP deviation above.
• Valid/invalid classification agrees with check-jsonschema 0.29.4, the version used by the dpp-criteria CI.

Reference passport

https://dpp.oydapp.eu/01/09520123456788/21/000001:

• DPP-DAT-016 failed: one violation, "Content-Type is application/json; charset=utf-8, expected text/html". The Vary warning on the JSON response no longer appears. The request with Accept */* passes.
• Overall: 12 of 13 automated checks passed, 1 failed, 1 warning (DPP-ID-016), 9 skipped.

Results are from automated checks only and establish no presumption of conformity.

Open questions for dpp-criteria

1. Which regex dialect applies to matches and search() in applies_if? The format covers only assertions and base_matches; RFC 9535 uses I-Regexp (RFC 9485).
2. Does content_type: application/json also require a single JSON object, and does that count as part of the content type for the order of evaluation?
3. Should "Results" define skipped for patterns that are invalid or outside the portable subset at run time?
4. Should the format rule out characters outside the BMP in . and character classes, or define matching on code points?