Page MenuHomePhabricator

Configure varnish to use "Unconfigured domain" page for 404 Not Served (instead of generic error)
Closed, DeclinedPublic

Description

When e.g. accessing https://misc-web-lb.wikimedia.org/ over HTTP it currently serves a generic Wikimedia server error page (with a buried detail of "404, Domain not served here" in the footnotes).

Maybe it would make more sense to use the "Unconfigured domain" page instead, such used by app servers to respond to unknown domains pointing at text-lb (I can't think of one in production at the moment, but see http://unknown.beta.wmflabs.org/ for example)

Screen Shot 2015-09-11 at 20.17.46.png (1×1 px, 157 KB)

Screen Shot 2015-09-11 at 20.18.04.png (618×1 px, 103 KB)

The error details footer seems useful though, since this is technically a much lower-level triggered error. So we'll want to keep that.

I'm thinking maybe we can actually do the inverse and move the docroot/default from the operations/mediawiki-config repo to puppet (near the errorpage template), and have puppet create docroot/default for app servers. That way we can easily re-use these templates, keep their design and implementation consistent, as well as update them in one for future design changes and improvements.

Event Timeline

Krinkle raised the priority of this task from to Low.
Krinkle updated the task description. (Show Details)
Krinkle added projects: acl*sre-team, Varnish.
Krinkle subscribed.

@ema Would it be possible (and acceptable) to add a condition somewhere in VCL that for the built-in error of Unconfigured domain to synthethise a different HTML response rather than the default one?

Now that we have it generated via a template (puppet:mediawiki/errorpage), it would be fairly trivial to replicate the HTML page we have in wmf-config/docroots/default from Varnish. I'd be happy to write a patch for that if you give me a pointer or two on how to add this.

They are both based on the same template now. It is just the message heading that is suboptimal. But, I don't think it adds much value to differentiate here how things work internally and how we communicate it externally given this should never be seen by anyone under normal conditions.

It also isn't unreasonable to assume that in fact when you see this there is in fact a technical problem.