NSURLRequest 向 IIS 服务器发出错误请求 (400)

发布于 2024-09-17 16:34:44 字数 960 浏览 12 评论 0原文

我正在构建一个 iPhone 应用程序,用于从 IIS7 服务器检索文件。我正在使用普通的旧 NSURLRequest 来检索此文件。如果我使用另一台 Web 服务器,该请求工作正常,但由于某种原因,该服务器不断向我发出 400 错误请求。所以我看了一下 NSURLRequest 发送的请求,它看起来像这样:

::1 [Wed Sep 01 20:18:53 -0400 2010]: GET /some.file
::1 [Wed Sep 01 20:18:53 -0400 2010]:  HTTP/1.1
::1 [Wed Sep 01 20:18:53 -0400 2010]: Host: localhost
::1 [Wed Sep 01 20:18:53 -0400 2010]: User-Agent: MyApp/1.0 CFNetwork/485.2 Darwin/10.4.0
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept: */*
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept-Language: en-us
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept-Encoding: gzip, deflate
::1 [Wed Sep 01 20:18:53 -0400 2010]: Connection: keep-alive
::1 [Wed Sep 01 20:18:53 -0400 2010]: 

我使用 telnet 并直接连接到网络服务器。发送以下内容:

GET /some.file HTTP/1.1\r\n

这工作正常,服务器用文件响应。

我有一种感觉,NSURLRequest 将 HTTP/1.1 放在另一行会导致 IIS7 返回错误请求。

有人知道我该如何补救这种情况吗?我不介意在服务器或客户端上进行更改,但不幸的是我坚持使用 IIS。

谢谢

I am building an iPhone app the retrieves a file from an IIS7 server. I'm using a plain old NSURLRequest to retrieve this file. The request works fine if I use another web server, but for some reason this one keeps giving me a 400 bad request. So I took a look at the request the NSURLRequest sends, and it looks like this:

::1 [Wed Sep 01 20:18:53 -0400 2010]: GET /some.file
::1 [Wed Sep 01 20:18:53 -0400 2010]:  HTTP/1.1
::1 [Wed Sep 01 20:18:53 -0400 2010]: Host: localhost
::1 [Wed Sep 01 20:18:53 -0400 2010]: User-Agent: MyApp/1.0 CFNetwork/485.2 Darwin/10.4.0
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept: */*
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept-Language: en-us
::1 [Wed Sep 01 20:18:53 -0400 2010]: Accept-Encoding: gzip, deflate
::1 [Wed Sep 01 20:18:53 -0400 2010]: Connection: keep-alive
::1 [Wed Sep 01 20:18:53 -0400 2010]: 

I used telnet and connected directly to the webserver. Sent the following:

GET /some.file HTTP/1.1\r\n

This worked fine, the server responded with the file.

I have a feeling that the fact that NSURLRequest puts HTTP/1.1 on another line causes IIS7 to return a Bad Request.

Anyone know how I can remedy this situation? I don't mind making changes on the server or client, but unfortunately i'm stuck with IIS.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

轻拂→两袖风尘 2024-09-24 16:34:44

弄清楚了...我的 URL 末尾有一个 \n 。难怪 NSURLRequest 将 HTTP/1.1 放在另一行。我很惊讶 NSURL 没有清理字符串。哇。

Figured it out...my URL had a \n at the end. No wonder NSURLRequest was placing HTTP/1.1 on another line. I'm surprised NSURL doesn't clean up the string. wow.

暗恋未遂 2024-09-24 16:34:44

我有一个类似的设置(但不是 IIS):GET 请求,在 iOS/Swift 代码 (NSURLSession) 上使用 HTTP 400 失败,但是有效 > 关于邮递员和卷曲。

经过几个小时的尝试找出每个客户端发送的请求之间可能存在的差异后,我发现我的 iOS 代码正在发送一个空的 swift 字典(类型为 [String : Any ])在请求正文中编码为 JSON。

我设计的客户端代码采用非可选字典作为请求参数,并将其编码/附加到请求正文,无论其内容如何。某些请求(例如我尝试的请求)不需要正文中的任何参数,并且空字典不知何故导致了问题。删除它修复了连接。

(我现在将重构我的函数,以采用可选字典作为参数,并为在正文中不带参数的请求传递nil

)也许是OP的问题,但相关。以防万一它可以帮助某人避免失去痛苦的时间......

I had a similar setup (not IIS, though): GET request, fails with HTTP 400 on iOS/Swift code (NSURLSession), but works on Postman and curl.

After hours and hours of trying to figure out what could possibly be different between the requests sent from each client, I discovered my iOS code was sending an empty swift dictionary (of type [String : Any]) encoded as JSON in the request body.

I designed my client code to take a non-optional dictionary as the request parameters, and encode it/append it to the request body regardless of its contents. Some requests (like the one I was attempting) do not require any parameters in the body, and somehow the empty dict was causing problems. Removing it fixed the connection.

(I will now refactor my function to take an optional dictionary as the argument instead, and pass nil for requests that take no parameters in the body.)

Not a solution to the OP's question perhaps, but related. Here just in case it helps someone avoid lost hours of misery...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文