Question

给定一个共享的HTTP管理器，似乎如果requestBody的类型为requestBodySource，并且如果为请求主体提供了错误的长度，则后续请求将在同一个HTTP管理器上废弃20秒似乎有一些关于共享状态和GivesPopper的交互可能会引起这个问题。下面是一个重现它的示例代码 - 我们使用requestb.in发送错误的长度上传，然后尝试在requestb.in上读取另一个有效的URL。

{-# LANGUAGE OverloadedStrings #-}

import           Data.Conduit.Binary (sourceFile)
import           Network.HTTP.Conduit 
import           Network.HTTP.Types
import qualified Data.ByteString.Lazy as LBS
import System.IO
import Control.Monad.Trans.Resource (runResourceT)
import Control.Concurrent.Async (async,waitCatch)
import Control.Exception (displayException)

main :: IO ()
main = do
  {- Set up a ResourceT region with an available HTTP manager. -}
  httpmgr <- newManager tlsManagerSettings
  httpmgr2 <- newManager tlsManagerSettings
  let file ="out" -- some byte contents with length > 1
  lenb <- System.IO.withFile file ReadMode hFileSize
  let inbytes = sourceFile file 
  initReq <- parseUrl "http://requestb.in/saxbx3sa"
  putreq <- async $ runResourceT $ do
    let req = initReq { method = "POST",
      -- let us send wrong length in requestBodySource
      requestBody = (requestBodySource (fromIntegral $ lenb - 1) inbytes)}
    resp <- httpLbs req httpmgr 
    return (statusCode . responseStatus $ resp)
  putreqRes <- waitCatch putreq
  case putreqRes of
    Left e -> print $ displayException $ e
    Right r -> print $ r
  getreq <- async $ runResourceT $ do
    -- Let us do a GET on a different resource to see if it works
    initReq <- parseUrl "http://requestb.in/1l15sz21"
    let req = initReq { method = "GET"}
    resp <- httpLbs req httpmgr 
    return (statusCode . responseStatus $ resp)
  getreqRes <- waitCatch getreq
  case getreqRes of
    Left e -> print $ displayException $ e
    Right r -> print $ r

输出 - 首次错误上传时间为HTTP 200，后续GET请求会立即导致HTTP 400错误：

 *Main> main
    200
    "StatusCodeException (Status {statusCode = 400, statusMessage = \"Bad Request\"})
 [(\"Date\",\"Wed, 29 Jun 2016 11:54:59 GMT\"),(\"Content-Type\",\"text/html\"),
(\"Content-Length\",\"177\"),(\"Connection\",\"close\"),(\"Server\",\"-nginx\"),
(\"CF-RAY\",\"-\"),(\"X-Response-Body-Start\",\"<html>\\r\\n<head><title>400 Bad 
Request</title></head>\\r\\n<body bgcolor=\\\"white\\\">\\r\\n<center><h1>400 Bad 
Request</h1></center>\\r\\n<hr><center>cloudflare-
nginx</center>\\r\\n</body>\\r\\n</html>\\r\\n\"),(\"X-Request-URL\",\"GET 
http://requestb.in:80/saxbx3sa\")] (CJ {expose = []})"

使用不同的http管理器代替GET请求将返回HTTP 200。因此，http管理器中的共享状态似乎是这里的问题。

还有其他人观察过吗？我经历了HTTP Manager的github问题但是还没有看到这个报道。在错误的流长度上，行为不应该像在这里发生的那样破坏HTTP管理器。

我还为requestBodySource模拟了一个源文件，其中长度是正确的，但是由于模拟失败，源会中途中止（以模拟网络问题）。在这种情况下，没有错误。因此，似乎我们只有一种情况，即发送错误的长度而没有任何失败将导致某种共享状态在这里变得腐败，并在25秒内释放。

如果有人对此处发生的事情有任何见解，那将非常有帮助。我有一个强制执行正确的流长度的解决方法。但是，我想了解发生了什么，以便我可以避免在生产中遇到这种情况。

Answer 1

这是http-client as reported here的问题。它将它留给调用者以确保传递的内容长度是正确的。它是服务器的共享连接，似乎处于错误状态。根据实际长度与预期长度的不同，下一个请求的开头可能会被视为上一个请求正文的结尾，导致服务器误解下一个请求。

已经修复并通过pull request合并到主干中。解决方案是添加一个简单的长度验证。

发送错误的流长度时，HTTP管理器共享状态损坏

1 个答案: