Повреждение общего состояния диспетчера HTTP при отправке неверной длины для потока

Учитывая общий HTTP-менеджер, кажется, что если requestBody имеет тип requestBodySource и если для тела запроса указана неправильная длина, последующие запросы будут сгенерированы в том же HTTP-менеджере примерно на 20 секунд. Кажется, что-то есть во взаимодействии общего государства и GivesPopper возможно, это вызывает эту проблему. Вот пример кода, который воспроизводит его - мы используем requestb.in для отправки загрузки неправильной длины, а затем пытаемся прочитать другой действительный URL-адрес на requestb.in.

{-# 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-менеджере, похоже, является проблемой здесь.

Кто-нибудь еще это наблюдал? Я прошел через вопросы GitHub для HTTP Manager но не видел этого сообщили. При неправильной длине потока поведение не должно приводить к повреждению HTTP-менеджера, как это происходит здесь.

Я также смоделировал исходный файл для requestBodySource, где длина верна, но источник прерывается на полпути из-за смоделированного сбоя (для имитации сетевых проблем). В этом случае ошибок нет. Итак, кажется, у нас есть только один случай, когда отправка неправильной длины без сбоев приведет к повреждению какого-то общего состояния, которое освобождается в течение 25 секунд.

Если у кого-то есть понимание того, что здесь происходит, это будет очень полезно. У меня есть обходной путь для обеспечения правильной длины потоковой передачи. Тем не менее, я хотел бы понять, что происходит, чтобы избежать такой ситуации на производстве.

Источник

1 ответ

Решение

Это проблема с http-client как сообщается здесь. Он оставляет это до вызывающей стороны, чтобы убедиться, что длина передаваемого содержимого является правильной. Это общее соединение с сервером, которое, кажется, в плохом состоянии. В зависимости от фактической длины относительно ожидаемой длины начало следующего запроса может рассматриваться как конец предыдущего тела запроса, что приводит к тому, что следующий запрос будет неверно истолкован сервером.

Это было исправлено и слито в магистраль через запрос на извлечение. Решением было добавить простую проверку длины.

Источник
Другие вопросы по тегам