問題タブ [http-conduit]

理解します "。" (ドット) 関数合成として。「|」はわかりました。（パイプ）「または」ガード導入構文（ここから ）としてですが、「.|」を使用したhttp-conduitsに関する回答を見ました それは私が理解できない方法でこの演算子を利用しています。

私が見つけたコンジットの他の参考文献は次のとおりです。

• https://docs.google.com/presentation/d/1RBefOCZ7AKOo4f1yiF4mtKPAT3l5vY9ky2SR02O4Vvg/edit#slide=id.g3c22e35a9_0205
• http://www.yesodweb.com/blog/2014/03/network-conduit-async

...データ フローでコンジットを結合するための "$$"、"$="、"=$="、"=$" などの構文を提案します。

これを「.|」と呼ぶにはどうすればよいですか この演算子とそれはどのように機能しますか?

予想どおり、「.| haskell」または「'dot pipe' haskell」または「'dot pipe' haskell operator circuits」のグーグル検索はあまり成功しませんでした。

私はhttp-conduitライブラリを試していて、この簡単な例があります:

この投稿から、[Char] または String よりも ByteString としての応答を優先する必要があることを理解しています。OverloadedStrings プラグマによってこの問題が軽減される可能性があると想定しましたが、私の out-type に関しては変化していないようです。

この関数は問題なく動作し、SO のホームページに対する単純な http 応答を忠実に出力しますが、その型シグネチャは非常に見苦しく見えます。

そして、インターネットの例からそのようなものはほとんど見られないと言わざるを得ません (楕円形の Java インポートよりも多くのドットがあります)。そうですか？応答を返したい場合、HXT、tagsoup、または attoparsec などを使用して解析を開始しますが、これは正しいアプローチまたは型シグネチャですか?

たとえば、別の URL を指定するなど、引数を取る機能を追加し始めると、これはさらに醜くなることに気付きました。

これは不健康に思えます。これを正しく構造化する方法をどのように理解すればよいですか?

http-clientチュートリアルを使用して、TLS 接続を使用して応答本文を取得しています。printによって呼び出されていることを確認できるので、次のフラグメントの出力への応答全体を強制withResponseしないのはなぜですか?print

代わりにこれを書く必要があります：

印刷したい本文は怠惰なByteStringです。print値全体を出力する必要があるかどうかはまだわかりません。

コード

スロー

約1kのリクエストの後。

ManagerSettingshttp-conduit アプリケーションのすべての要求と応答をログに記録するために、これを作成しました。（ちなみに、私はインポートしていますClassyPrelude）。

ただし、機能していません。使用すると、アプリケーションがハングし、最初の要求と最初の応答を出力した後、マシン内のすべての RAM を消費しようとします。これは、ある種の無限ループを示唆しています。

また、要求は 2 回出力されます。

私は似たような以前の試みをしましたが、変更しませんでしたr。応答を完全に読み取った後、読み取る応答データがなくなったため、失敗しました。

これを に置き換えるとtlsManagerSettings、http-conduit再び機能します。

私のアプリケーションは libstackexchange を使用していますが、これをManagerSettingsカスタマイズできるように変更しました。http-conduit バージョン 2.2.4 を使用しています。

問題を診断するにはどうすればよいですか? どうすれば修正できますか？