Yaws反向代理Docker部署Adminer HTTPS访问时CSS/JS不加载问题

在Docker容器中部署了Adminer，测试域名使用mydomain.tld，直接暴露端口8081映射到Adminer的8080端口时，通过http://mydomain.tld:8081访问完全正常，登录界面渲染正确。但该方案存在明文传输账号密码的安全隐患，因此不可用。

改用HTTPS访问同一个容器，通过https://mydomain.tld/adm路径请求，由监听443端口的Web服务器转发请求到Adminer容器处理。之前用nginx做反向代理时该方案运行正常，现在换成yaws做反向代理透传请求到Adminer容器后，页面出现渲染异常，Opera、Chrome、Firefox等所有浏览器都未加载CSS和JS文件。

仅Firefox控制台报出MIME类型错误：请求的default.css返回MIME类型为text/html而非text/css，functions.js返回MIME类型为text/html而非合法的JavaScript MIME类型。但HTML源码内的标签完全正确：

<link rel="stylesheet" type="text/css" href="?file=default.css&amp;version=4.8.1">
<script src='?file=functions.js&amp;version=4.8.1' nonce="ZDA0ODE4Y2ZhZWY1NzkyZTUxNzg3MGZlNTdlNTcxM2M="></script>

目前已验证以下几点：

• 同一份源码在HTTP 8081端口访问时完全正常
• 直接点击HTTPS页面源码里的CSS/JS链接可以正常加载对应文件
• 开发者工具网络面板显示所有资源请求状态码都是200

甚至修改Adminer容器输出的资源路径为完整路径也没有解决问题，本地测试时替换FULL_PATH为http://mydomain.tld:8081/时正常，替换为https://mydomain.tld/adm/时就出现加载异常。

• Yaws反向代理默认开启了自动MIME类型推断逻辑，会根据请求路径的后缀判断返回资源的类型。由于Adminer的静态资源通过?file=xxx查询参数返回，请求路径没有.css/.js这类明确的后缀，Yaws无法识别资源类型，默认填充了text/html的Content-Type响应头，直接覆盖了Adminer容器返回的正确MIME类型。
• 单独点击资源链接可正常加载的原因是，浏览器主动发起的单独请求会携带明确的Accept请求头，该场景下Yaws的自动推断规则优先级低于Accept头匹配规则，因此返回了正确类型，但页面内嵌的CSS/JS资源请求的Accept头优先级低于Yaws的路径匹配规则，导致返回了错误类型。

1. 验证上游Adminer返回的响应头是否正确，执行命令：

curl -v "http://localhost:8081/?file=default.css&version=4.8.1" 2>&1 | grep "Content-Type"

正常输出应为Content-Type: text/css，确认上游服务无异常。
2. 验证Yaws转发后的响应头是否异常，执行命令：

curl -v "https://mydomain.tld/adm/?file=default.css&version=4.8.1" 2>&1 | grep "Content-Type"

如果输出为Content-Type: text/html，即可确认是Yaws的头覆盖问题导致的故障。

1. 首选方案：修改Yaws对应站点的反向代理配置，添加revproxy_pass_header *配置项，开启所有上游响应头透传，关闭Yaws的自动MIME类型推断逻辑，让Adminer返回的原始Content-Type头直接传递到浏览器。
2. 备选方案：如果需要保留Yaws的部分头处理能力，可以单独添加自定义MIME匹配规则，当请求query参数中包含file=default.css时强制设置Content-Type为text/css，包含file=functions.js时强制设置为application/javascript。
3. 配置修改完成后重启Yaws服务，清空浏览器缓存重新访问即可恢复页面正常渲染。

内容的提问来源于stack exchange，提问作者kklepper