Page MenuHomePhabricator

Geo Analytics Implement header function
Closed, ResolvedPublic

Description

Background/Goal
Read T325827 for context

When executed locally, the new AQS 2.0 services are currently not sending the same response headers as the existing production service are when executed from our production infrastructure. Notably, there are differences in security- and caching-related headers, as well as some others. So as a part the above mentioned task a function has been created in aqassist to return some of these headers from code>

Acceptance Criteria
The service should be updated to implement the aqassist function, unit tests for the same should be added

Event Timeline

SGupta-WMF created this task.
SGupta-WMF renamed this task from Editor Analytics Implement header function to Geo Analytics Implement header function.May 4 2023, 8:56 AM

Change 919024 had a related patch set uploaded (by Santiago Faci; author: Santiago Faci):

[generated-data-platform/aqs/geo-analytics@main] middleware: Set security headers

https://gerrit.wikimedia.org/r/919024

Change 919024 merged by Sg912:

[generated-data-platform/aqs/geo-analytics@main] middleware: Set security headers

https://gerrit.wikimedia.org/r/919024

Production headers for Geo Analytics service:

{
   "cache-control":"s-maxage=14400, max-age=14400",
   "content-type":"application/json; charset=utf-8",
   "server":"restbase2025",
   "date":"Mon, 22 May 2023 13:47:06 GMT",
   "access-control-allow-origin":"*",
   "access-control-allow-methods":"GET,HEAD",
   "access-control-allow-headers":"accept, content-type, content-length, cache-control, accept-language, api-user-agent, if-match, if-modified-since, if-none-match, dnt, accept-encoding",
   "access-control-expose-headers":"etag",
   "x-content-type-options":"nosniff",
   "x-frame-options":"SAMEORIGIN",
   "referrer-policy":"origin-when-cross-origin",
   "x-xss-protection":"1; mode=block",
   "content-security-policy":"default-src 'none'; frame-ancestors 'none'",
   "x-content-security-policy":"default-src 'none'; frame-ancestors 'none'",
   "x-webkit-csp":"default-src 'none'; frame-ancestors 'none'",
   "content-encoding":"gzip",
   "vary":"Accept-Encoding",
   "age":"661",
   "x-cache":"cp2035 miss, cp2027 hit/1",
   "x-cache-status":"hit-front",
   "server-timing":"cache;desc=\"hit-front\", host;desc=\"cp2027\"",
   "strict-transport-security":"max-age=106384710; includeSubDomains; preload",
   "report-to":"{ \"group\": \"wm_nel\", \"max_age\": 604800, \"endpoints\": [{ \"url\": \"https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0\" }] }",
   "nel":"{ \"report_to\": \"wm_nel\", \"max_age\": 604800, \"failure_fraction\": 0.05, \"success_fraction\": 0.0}",
   "set-cookie":"WMF-Last-Access=22-May-2023;Path=/;HttpOnly;secure;Expires=Fri, 23 Jun 2023 12:00:00 GMT, WMF-Last-Access-Global=22-May-2023;Path=/;Domain=.wikimedia.org;HttpOnly;secure;Expires=Fri, 23 Jun 2023 12:00:00 GMT, GeoIP=US:TX:Katy:29.74:-95.83:v4; Path=/; secure; Domain=.wikimedia.org",
   "x-client-ip":"2601:2c2:1:93c0:e9a6:798a:65af:9325",
   "accept-ranges":"bytes",
   "content-length":"698"
}

Local AQS 2.0 headers for Geo Analytics service:

{
   "Access-Control-Allow-Headers":"accept, content-type, content-length, cache-control, accept-language, api-user-agent, if-match, if-modified-since, if-none-match, dnt, accept-encoding",
   "Access-Control-Allow-Methods":"GET,HEAD",
   "Access-Control-Allow-Origin":"*",
   "Access-Control-Expose-Headers":"etag",
   "Cache-Control":"s-maxage=14400, max-age=14400",
   "Content-Security-Policy":"default-src 'none'; frame-ancestors 'none'",
   "Content-Type":"application/problem+json",
   "Referrer-Policy":"origin-when-cross-origin",
   "X-Content-Type-Options":"nosniff",
   "X-Frame-Options":"deny",
   "X-Xss-Protection":"1; mode=block",
   "Date":"Mon, 22 May 2023 13:58:45 GMT",
   "Content-Length":"162"
}

@SGupta-WMF @BPirkle I know not all the headers might be implemented, if what we have suffices then this is good.

I am a bit concerned why for our AQS 2.0 we have "Content-Type":"application/problem+json" instead of "content-type":"application/json; charset=utf-8" in production

I am a bit concerned why for our AQS 2.0 we have "Content-Type":"application/problem+json" instead of "content-type":"application/json; charset=utf-8" in production

Good question, and glad you flagged it because normally this might indicate an issue.

In this case, however, AQS 2.0 is correct. See:

In particular, search within the RFC for "content-type" and you'll see it specifies "Content-Type: application/problem+json". Reading through the task, although we didn't mention this particular header, you'll see that we generally agreed to follow the standard set forth in the RFC in cases like this where the existing production AQS deviates from the RFC and changing the behavior is unlikely to negatively affect clients.

If you're concerned about "Content-Type" vs "content-type", don't be. Header names are case-insensitive, per RFC 7230, section 3.2.

@BPirkle thanks for clarifying this. In that case we can call this ticket good