4

このスニペットを考えると：

(defroutes main-routes
    (POST "/input/:controller" request
        (let [buff (ByteArrayOutputStream.)]
            (copy (request :body) buff) 
            ;; --- snip

リクエストにContent-Typeヘッダーがある場合、buffの値は空ではないバイト配列になります。値は無意味である可能性があり、ヘッダーはそこにある必要があります。

ただし、クライアントが問題のあるアップロードを追跡できるように、リクエストがコンテンツタイプなしで送信された場合は、本文をダンプする必要があります（うーん...間違って出てきました）。（アップロードソフトウェアは私の管理下にはなく、そのメンテナはヘッダーに余分なものを提供しません。）

これを解決または回避する方法についてのアイデアをありがとう！

編集：

クライアントから取得したヘッダーは次のとおりです。

{
   "content-length" "159",
   "accept" "*/*",
   "host" (snip),
   "user-agent" (snip)
}

さらに、Ringは、JavaのServletRequestのインスタンスを使用して、コンテンツタイプに標準のデフォルトであるx-www-form-urlencodedを入力することを発見しました。HTTPParser＃Inputを介して本体を提供するHTTPParserは、正しく解析できないと推測しています。

4

2 に答える 2

1

私は同じ問題に直面しています。これは間違いなく、本体を正しく解析して変換できないミドルウェアの1つです:body。主な問題はContent-Type、本体が解析可能であることを提案することです。

を使用して、ミドルウェアngrepがどのように混乱するかを見つけました。curl次のコマンドラインは直感的（またはかなりセクシー）Content-Typeですが、ミドルウェアを混乱させる間違ったメッセージを送信します。

curl -nd "Unknown error" http://localhost:3000/event/error                                                                            

T 127.0.0.1:44440 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Length: 13.
Content-Type: application/x-www-form-urlencoded.
.
Unknown error

ただし、次の場合、Content-Typeは不透明になり、ミドルウェアは干渉しません:body。

curl -nd "Unknown error" -H "Content-Type: application/data" http://localhost:3000/event/error                                        

T 127.0.0.1:44441 -> 127.0.0.1:3000 [AP]
POST /event/error HTTP/1.1.
Authorization: Basic SzM5Mjg6ODc2NXJkZmdoam5idmNkOQ==.
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3.
Host: localhost:3000.
Accept: */*.
Content-Type: application/data.
Content-Length: 13.
.
Unknown error

リクエストが間違っていても、自分で体をどうするか決めたいので、ミドルウェアをもっとリベラルなものに交換することを考えています。リクエストが意味をなさないときにリクエスト本文をゼロにするのは本当に奇妙な選択です。400 Bad Request実際には、より正しい動作は、デフォルトでまたはを返すエラーハンドラーに渡すことだと思います406 Not Acceptable。

それについて何か考えはありますか？私の場合、Compojureにパッチを提案するかもしれません。

于 2012-05-23T18:19:28.003 に答える
1

によると：

http://mmcgrana.github.com/ring/ring.middleware.content-type-api.html

デフォルトのコンテンツタイプはapplication/octet-streamです。そのコンテンツタイプを積極的にサポートしていない限り、コンテンツタイプがそのコンテンツタイプと一致するかどうかを確認し、それに基づいて必要なものをダンプすることはできませんか？

于 2011-11-21T17:18:51.597 に答える