1

我们有一个在谷歌云上运行的快速服务器。当我们的服务器尝试使用 204 的 HTTP 状态代码进行响应时，这将转换为 502 Bad Gateway。我已经确认这只发生在 GCP 中。在这个特定示例中，我们使用的是 Google 的完全托管端点。在我的本地机器上运行它会产生预期的结果。此外，使用相同的代码发送 200 状态代码也可以成功。

错误代码：upstream connect error or disconnect/reset before headers. reset reason: protocol error

这是我们以 204 状态码响应的 express 端点：

app.post('/', [cors(corsConfig), jsonParser], async (req, res) => {

  res.setTimeout(timeout, () => {
    log(’timeout’)
    res.sendStatus('204');
    res.end();
  });

});

连接细节：

  • 利用 Google 的托管端点
  • HTTP/2禁用

这是我们的 Dockerfile：

# Use the official lightweight Node.js 12 image.
# https://hub.docker.com/_/node
FROM node:12-slim AS base

# Create and change to the app directory.
WORKDIR /usr/src/app

# Run our webpack build inside a separate stage
FROM base AS build

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
# Copying this separately prevents re-running npm install on every code change.
COPY package*.json ./
COPY yarn.lock ./

# Install all dependencies for a build
RUN yarn

COPY . ./
RUN yarn build

FROM base AS runtime

COPY package*.json ./
COPY yarn.lock ./

# Copy only the built app output
COPY --from=build /usr/src/app/dist ./dist

# Re-install only production dependencies, to reduce image size ($$)
RUN yarn --only=production

COPY public ./public
COPY partners.yml ./

# Run the web service on container startup.
CMD [ "yarn", "start" ]
4

1 回答 1

0

我们在 Google Cloud Run 中的 Django 应用程序中遇到了同样的问题。问题是我们的应用程序没有按照 204 状态的要求发送空响应正文。我们使用的框架在我们的空结果周围添加了一些包装。

许多服务器错误地在 204 响应中发送正文，因此浏览器通常使用启发式方法来查看响应正文是否存在（链接）。Cloud Run 代理似乎严格遵守标准，这会在存在响应正文时导致 HTTP 协议错误。

要修复它，您需要确保从应用程序返回一个实际为空的响应，或者只使用 200 状态代码。

于 2021-08-16T14:21:29.717 回答