Page MenuHomePhabricator

RESTBase warning missing Content-Language or Vary header in pb.body.html.headers
Closed, ResolvedPublic

Description

After traffic mirroring was deployed, Missing Content-Language or Vary header in pb.body.html.headers warn logs started appearing in RESTBase dashboard.

This warning is if there's no content-language or vary header in parsoid response. See T236382 and T221174 for more details.

Event Timeline

Pchelolo created this task.Oct 29 2019, 7:27 PM
ssastry triaged this task as Medium priority.Oct 29 2019, 8:58 PM
ssastry moved this task from Backlog to Bugs, Notices, Crashers on the Parsoid-PHP board.

Looking at the log, there are some oddities,

api_path	   	/bcl.wikipedia.org/v1/page/html/{title}

but

root_req.uri	   	/en.wikipedia.org/v1/page/html/User%3ABSitzmann_%28WMF%29%2FMCS%2FTest%2FFrankenstein

I imagine this would hit this validation exception,
https://github.com/wikimedia/parsoid/blob/master/extension/src/Rest/Handler/ParsoidHandler.php#L114-L141

The user agent is,

root_req.headers.user-agent	   	ServiceChecker-WMF/0.1.2

not sure what that's doing.

From scandium, if I curl -H "Host: en.wikipedia.org" https://parsoid-php.discovery.wmnet/w/rest.php/en.wikipedia.org/v3/page/pagebundle/User%3ABSitzmann_%28WMF%29%2FMCS%2FTest%2FFrankenstein/860183819

I get,

{"contentmodel":"","html":{"headers":{"content-type":"text/html; charset=utf-8; profile=\"https://www.mediawiki.org/wiki/Specs/HTML/2.1.0\"","content-language":"en","vary":"Accept"},"body":"<!DOCTYPE html>\n<html prefix=\"dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/\" about=\"https://en.wikipedia.org/wiki/Special:Redirect/revision/860183819\"> ...

The api_path property in the log is probably incorrect, it's a long standing RESTBase bug.. I will have a look at this from RESTBase perspective tomorrow.

I will have a look at this from RESTBase perspective tomorrow.

Ok, thank you

Pchelolo closed this task as Resolved.Oct 30 2019, 4:18 PM
Pchelolo claimed this task.

Hm... Somehow the errors were mostly coming from service-checker requests and rerendering the page has completely fixed the problem. Maybe some bogus data was stored during the deploy when the cluster was in transitional configuration. I'll close this for now, will reopen if it happens again.