当API返回204没有内容时使用“gulp服务”获取代理错误
我正在使用Gulp来开发由Yeoman的吞咽angular生成器生成的Angular应用程序。 我已经configuration它代理请求到/api到另一个端口，我的API正在监听的端口。 该端口实际上是通过SSH隧道转发到外部服务器。
这里是我为自己的API编辑的Yeoman生成的configuration：
一饮而尽/ server.js
'use strict'; var gulp = require('gulp'); var browserSync = require('browser-sync'); var httpProxy = require('http-proxy'); /* This configuration allow you to configure browser sync to proxy your backend */ var proxyTarget = 'http://localhost:3434/api'; // The location of your backend var proxyApiPrefix = 'api'; // The element in the URL which differentiate between API request and static file request var proxy = httpProxy.createProxyServer({ target: proxyTarget }); function proxyMiddleware(req, res, next) { if (req.url.indexOf(proxyApiPrefix) !== -1) { proxy.web(req, res); } else { next(); } // ...rest of config truncated
标准输出
[BS] Watching files... /Users/jason/dev/web/node_modules/http-proxy/lib/http-proxy/index.js:114 throw err; ^ Error: Parse Error at Socket.socketOnData (http.js:1583:20) at TCP.onread (net.js:527:27)
当我的应用程序试图击中一个特定的API url，发送回应204，没有内容，我得到了上述错误。
url结构： POST / api / resource / delete（API不支持实际的DELETE http方法，所以我们POST到这个端点）
回应： 204无内容
该API也在开发中，并通过内置的PHP Web服务器提供服务。 服务器告诉我们的是，在PHP可以发送响应之前，客户端（在这种情况下也称为Node，因为它是代理服务器）挂起。
我想也许只是因为没有内容而感到窒息。 所以，我们创build了第二个终结点，它也返回了204无内容，它似乎工作正常。 但是，公平的说，这个问题似乎是间歇性的 – 有时候有效，有时却不行。 这很混乱。
据我们所知，它只发生在这个删除url上。 我对Node非常陌生，我很难搞清楚问题在哪里或在哪里寻找。 有没有人有任何线索或有任何人见过这个？
事实certificate，API的开发者发送了我的内容，当他不应该的时候 – 一些debugging代码留在了。节点代理使用的HTTPparsing器然后在开始时从缓冲区读取那个内容的后续请求，然后抛出一个错误，因为它没有看到一个正确形成的HTTP请求 – 因为缓冲区中的第一件事是一个PHP var_dump。
碰巧，我的前端应用程序进行了删除调用，然后通过GET请求刷新另一个对象。 它们发生得如此之快，看起来像DELETE调用杀死了吞噬服务器，事实上这是后来的GET命令。
用于节点的http-proxy模块明确地不执行error handling，将最终用户的责任留给用户。 如果你没有处理错误，它就会冒泡成一个未被捕获的exception，并会导致应用程序closures，就像我看到的那样。
所以，解决方法很简单：
一饮而尽/ server.js
var proxy = httpProxy.createProxyServer({ target: proxyTarget }).on('error', function(e) { console.log(JSON.stringify(e, null, ' ')) });
控制台现在将logging所有的代理错误，但是这个过程不会消失，随后的请求将继续按预期的方式提供服务。
对于有问题的错误，控制台输出是：
{ "bytesParsed": 191, "code": "HPE_INVALID_CONSTANT" }
另外，我们已经修复了API以履行其204，实际上，不知道发送内容。