Twilio调用Google Apps Script返回HTTP 413错误排查求助

针对你遇到的Twilio请求GAS返回PDF时出现413响应过大的问题，以下是几个容易忽略的点：

• HTTP请求头不匹配
  手动用HTTPie/Postman测试时的请求头和Twilio自动发送的可能存在差异。比如Twilio请求时未指定Accept: application/pdf，导致GAS返回的内容被额外包装（如HTML格式的错误提示或默认响应），间接导致响应体积超出Twilio的解析阈值。
  解决：在Twilio的请求逻辑中显式设置Accept和Content-Type头为application/pdf，确保GAS返回纯PDF二进制内容。

• GAS未正确返回PDF流
  若GAS的响应未正确设置MIME类型和响应头，可能导致Twilio解析时将额外的响应元数据或包装内容计入体积。需确保GAS直接输出PDF的二进制数据：

  function doGet(e) {
    // 生成或获取PDF Blob
    const pdfBlob = DriveApp.getFileById('你的PDF文件ID').getBlob();
    const response = ContentService.createTextOutput();
    response.setContent(pdfBlob.getBytes());
    response.setMimeType(ContentService.MimeType.PDF);
    // 设置必要头信息避免额外包装
    response.setHeaders({
      'Content-Disposition': 'inline',
      'Content-Length': pdfBlob.getSize().toString()
    });
    return response;
  }
  

• Drive导出链接的重定向问题
  Google Drive的导出链接通常会触发302重定向，而Twilio处理MediaURL时可能无法正确跟进重定向，导致将重定向响应内容与PDF内容合并，最终响应体积超标。
  解决：不要直接返回Drive导出链接，改为在GAS内部读取PDF文件的Blob并直接输出给Twilio，跳过Drive的重定向环节。

• Twilio请求的隐性限制
  虽然Twilio官方标注5MB上限，但对响应的格式、编码方式有隐性要求。比如若GAS返回的PDF采用了非标准编码，可能被Twilio错误计算体积。
  解决：检查GAS返回的PDF是否为标准的二进制流，避免在输出前进行Base64编码（除非Twilio明确要求）。

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