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

根据：

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

默认内容类型是application/octet-stream. 除非您积极支持该内容类型，否则您不能仅检查内容类型是否与该内容类型匹配，然后根据该内容转储您需要的任何内容吗？

于 2011-11-21T17:18:51.597 回答
1

我面临同样的问题。这绝对是无法正确解析 body 和转换的中间件之一: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

我正在考虑用更自由的中间件替换中间件，因为即使请求是错误的，我仍然希望能够自己决定如何处理身体。当请求没有意义时，将请求正文归零是一个非常奇怪的选择。我实际上认为更正确的行为是将其传递给错误处理程序，默认情况下将返回 a 400 Bad Requestor 406 Not Acceptable。

对此有什么想法吗？就我而言，我可能会为 Compojure 提出一个补丁。

于 2012-05-23T18:19:28.003 回答