我正在研究一个巧妙的计划,涉及使用node.js作为另一个服务前面的代理服务器。
简而言之:
1.将传入的请求分派到静态文件(如果存在)
1.否则,将请求分派到另一个服务
我有基本的工作,但现在试图让整个事情与 Sencha Connect工作,所以我可以访问所有的踢屁股中间件提供。
所有操作都发生在下面的 dispatchProxy 中
connect(
connect.logger(),
connect.static(__dirname + '/public'),
(request, response) ->
dispatchProxy(request, response)
).listen(8000)
dispatchProxy = (request, response) ->
options = {host: host, port: port, method: request.method, headers: request.headers, path: request.url}
proxyRequest = http.request(options, (proxyResponse) ->
proxyResponse.on('data', (chunk) ->
response.write(chunk, 'binary')
)
proxyResponse.on('end', (chunk) ->
response.end()
)
response.writeHead proxyResponse.statusCode, proxyResponse.headers
)
request.on('data', (chunk) ->
proxyRequest.write(chunk, 'binary')
)
# this is never triggered for GETs
request.on('end', ->
proxyRequest.end()
)
# so I have to have this here
proxyRequest.end()
您会注意到上面最后一行的***proxyRequest.end()***。
我发现在处理GET请求时,请求的END事件永远不会被触发,因此需要调用proxyRequest.end()。POST请求按预期触发DATA和END事件。
那么几个问题:
- 这个对proxyRequest.end()的调用安全吗?也就是说,即使在事件循环之外调用proxyResponse,它仍然会完成吗?
- GET不触发END事件是正常的,还是END被捕获在连接堆栈的某个地方?
2条答案
按热度按时间azpvetkf1#
问题不在于
end
事件,而在于data
事件。如果客户端发出GET请求,则只有头而没有数据。这与POST不同,在POST中,请求者发送数据,因此on("data")
处理程序被命中。所以(请原谅我的JS示例,我对coffeescript不太熟悉):如果我对这个服务器进行curl调用,数据事件永远不会被命中,因为
GET
请求只不过是头文件。正因为如此,你的逻辑变成了:所以,由于我刚才提到的逻辑分支,你将不得不手动调用
proxyRequest.end()
来处理GET
请求。jjhzyzn02#
我的经验是,
request.on('end',)
不会被“一致地”调用,除非它是一个POST。我怀疑在脚本有机会检测到它之前,(某人发出http.request的)事件就已经结束了。