Background Information

Other than providing a storage layer, RESTBase implements some logic for the services that it proxies the requests.
Specifically:

• lib/access_check_filter.js
  • Checks if a page is restriced and returns a redirect instead
• lib/security_response_header_filter.js
  • Adds security related headers to responses
    • CSP
    • CORS
    • x-content-type-options, x-frame-options
    • referrer-policy
    • x-xss-protection
• lib/language_variants_filter.js
  • Checks MW API for language variants for each request and adds language headers
• lib/ensure_content_type.js
  • Enforces the response content type
    1. compares the returned content-type with the first entry of the produces array in the route spec, and
    2. repeats the request with no-cache header set if:
       • the profile parameter does not match, and
       • either the path (without version) differs, or the expected version is higher than the returned version, and
       • the page has not been re-rendered within the last two minutes.

What

We need to make sure that all of them are still needed and provide compatibility on mobileapps level when serving requests without RESTBase

Acceptance Criteria

• PCS applies lib/access_check_filter.js logic without RESTBase T321195
• PCS applies lib/security_response_header_filter.js logic without RESTBase T321194
• PCS applies lib/ensure_content_type.js logic without RESTBase T321199
• PCS applies lib/language_variants_filter.js logic without RESTBase T317019
  • Ensure PCS does not need a compatibility layer

In T314771#8327342, @daniel wrote:

• lib/language_variants_filter.js
  • Checks MW API for language variants for each request and adds language headers

The v1/page/{title} endpoint will soon have support for this, see T317019