来自 IIS6 的 getJSON 响应中的 JSON 为空,而不是 IIS7?使用 MVC2、jQuery、Ajax

发布于 2024-10-18 10:58:30 字数 2743 浏览 0 评论 0原文

新来的。我已经搜索了很多关于我的问题的有效解决方案,但即使我找到了标题有希望的帖子,但没有一个解决方案有效。

我正在将 MVC2 Web 应用程序部署到客户端的服务器。

我在 Win2k8 服务器上进行开发,但他们正在运行 Win2k3 服务器。

该应用程序的唯一目的是接收一些记录 ID 信息作为 HTTP 参数,在数据库中检查给定记录的状态,然后以简单字符串形式返回状态信息,例如 JSON 中的“已完成”或“未完成”格式。

这段 getJSON 代码在开发环境中运行良好。

让我感到莫名其妙的是,在客户端的服务器上,getJSON 请求从应用程序接收到空响应。

AFAIK 没有跨域操作...结果与来自客户端服务器或通过 VPN 来自我的机器的结果相同。

在MVC模型的Json代码中,人们常见的解决方案是在返回的Json结果中添加“JsonRequestBehavior.AllowGet”属性。我在尝试部署它之前很久就这样做了,正如我所说,它在开发环境中运行良好。

使用 Firebug,我看到相同的请求 URL 被发送到我的本地服务器和客户端服务器 - 来自两个服务器的响应标头是相同的,但来自我的服务器的响应内容显示为:

{"Result":"No Data"}

这就是我想要的。

客户端服务器的响应中实际上没有显示任何内容..?但请求会收到 HTTP 200 代码,并在响应的状态属性中记录为成功。

这两种情况下的响应头内容类型都是“application/json”

但是等等,还有更多!

如果我在 Firefox 导航栏中手动输入对每个服务器的请求,然后按 Enter,在两种情况下它都会响应:

{"Result":"No Data"}

这就是我想要的。那么,为什么只有当我在 Firefox 中手动输入请求 URL 时,才能从客户端服务器上的 MVC 应用程序获得所需的结果,而不是从 Javascript 代码中获得结果呢?

我尝试过强制使用不同的输出内容类型...使用 jQuery ajaxSetup 方法...

$.ajaxSetup({
    async: false,
    dataType: 'text'
    }); 

或者

$.ajaxSetup({
    async: false,
    dataType: 'html'
    }); 

再次使用“script”和“json”。我还尝试了转换选项,例如“text json”或“html json”或“json text”等。

不过,我正在阅读的一些帖子以及我的直觉表明问题不在于发出错误请求的 jQuery 代码...我不明白相同的 jQuery 请求如何指向正在运行的不同服务器同一个应用程序会突然导致该服务器发回“空”值。

我想澄清的是,我的意思是没有发送任何内容。没有 {} 或 {null} 或任何 JSON 符号...只是不存在的空白 :P

即使没有人知道答案,我会喜欢一些输入,也许可以建议我应该在哪里集中我的侦查......客户端还是服务器?

如果问题出在服务器上,似乎很难真正知道 MVC 东西是否在 IIS6 服务器上 100% 运行,但总的来说它似乎可以工作。我在客户端服务器上运行一个不同的 MVC 应用程序,它响应虚拟路径,并且通常与在开发计算机上运行相同。

我发现一件事......请求标头有些不同?发送到 IIS7 设置的请求标头包括“X-Requested-With: XMLHttpRequest”、“referrer”和“cookie”字段/值。

我可以猜测 IIS6 请求标头中缺少“X-requested-with: XMLHttpRequest”是一个线索,但我不明白指向不同服务器的相同 javascript 代码如何本身生成不同的请求标头。那么这些是如何生成的呢?

顺便说一句,JavaScript 嵌入在 ASP.NET 页面中。

噢..沮丧!

感谢您的任何意见。


奇怪的进展...显然 IIS6 处理查询时存在某种问题。虽然我没有关注 JSONP,但其他地方的帖子建议有时使用“&callback=?” .getJSON 请求 URL 末尾的参数将强制其进入 GET 模式,并且该模式经常用于解决从服务器获取数据的问题。所以我就这么做了……而且确实有效。响应请求返回了正确的 {"Result":"No Data"}...这看起来不错。然而,JSONP 回调的工作方式是,它生成自己的脚本来调用、获取和解释传入的 JSON。在这种情况下,它会将 JSON 解释为需要一个它没有的标签,因此会抛出“无效标签”错误……必须有某种方法来破解某些内容以仅传递 JSON,但整个需要使用JSONP 回调表明服务器配置错误,对吗?或者为什么它在没有 JSONP 的情况下适用于 IIS7 而不是 IIS6?


尽管我不喜欢回调 JSONP 解决方案,但它似乎工作正常。仍然返回关于无效标签的错误,但这似乎并没有阻止剩余的 javascript 运行......因此应用程序现在正在使用 IIS6。我还没有测试针对 IIS7 使用回调和 JSONP 的修复,但我预计它会工作得足够好。


这是指向我的当前解决方案的讨论的链接。不过,我仍然希望找到一个更优雅的解决方案。

NeoWin.net

New here. I've searched quite a bit for a working solution to my problem, but even though I have found posts with promising titles, none of the solutions have worked.

I am deploying an MVC2 web app to a client's server.

I did my development on Win2k8 Server, but they are running Win2k3 sever.

The app's only purpose is to receive some record ID information as HTTP parameters, check in the database for the status of the given record or records, and then return the status information as a simple string such as "Completed" or "Incomplete" in JSON format.

This getJSON code works fine in the development environment.

Inexplicably to me, on the client's server, the getJSON request receives a null response from the application.

There is no cross-domain action AFAIK... the result is the same from the client's server or from my machine via VPN.

In the MVC model's Json code, a common solution for people is to add the "JsonRequestBehavior.AllowGet" attribute to the Json result being returned. I did this long before trying to deploy it, and as I said, it has worked fine in the dev environment.

Using Firebug, I have watched the same request URL get sent to both my local server and the client server - the response headers from both servers are the same, but the response content from my server is shown as:

{"Result":"No Data"}

Which is what I want.

There is literally no content shown in the response from the client's server..? But the request gets an HTTP 200 code and is recorded as a success in the reponse's status attribute.

The response header content type in both situations is "application/json"

But wait, there is more!

If I manually enter the request to each server in the Firefox nav bar, and hit enter, in both cases it responds with:

{"Result":"No Data"}

Which is what I want. So why can I get the result I want from the MVC app on the client's server only when I hand-enter the request URL in Firefox, but not from the Javascript code?

I have tried forcing different output content types ... using the jQuery ajaxSetup method...

$.ajaxSetup({
    async: false,
    dataType: 'text'
    }); 

or

$.ajaxSetup({
    async: false,
    dataType: 'html'
    }); 

and again wtih 'script', and 'json'. I also tried the conversion options such as 'text json' or 'html json' or 'json text' and so forth.

Some of the posts I'm reading, and my gut feeling, though, suggest the problem is not the jQuery code making the request that is at fault... I don't see how the same jQuery request point to a different server running the same app would suddenly cause that server to send back a 'null' value.

By null, I want to be clear... I mean nothing is sent. There is no {} or {null} or any sign of JSON... just blank whiteness of non-existence :P

Even if nobody knows the answer, I would love some input perhaps suggesting where I should focus my sleuthing ... client or server?

If the problem is the server, it seems hard to really know that the MVC stuff is running 100% on the IIS6 server, but in general it seems to work. I have a different MVC app running on the client server which responds to the virtual paths, and generally runs the same as on dev machine.

I have found one thing ... the request headers are somewhat different? The Request Headers sent to the IIS7 setup include an "X-Requested-With: XMLHttpRequest", "referrer" , and "cookie" field/value.

I could guess that the lack of the "X-requested-with: XMLHttpRequest" in the IIS6 request headers is a clue, but I do not see then how the same javascript code pointing at a different server can generate different request headers itself. So how else are those being generated?

The javascript is embedded in an ASP.NET page, btw.

Oooh.. frustration!

Thanks for any input.


Odd Progress ... apparently there is some sort of issue with IIS6 handling the query. Although I have not payed any attention to JSONP, a post elsewhere suggested that sometimes use the "&callback=?" parameter at the end of a .getJSON request URL would force it into GET mode and that worked frequently for problems getting data from the server. So I did that... and it did work, sort of. The proper {"Result":"No Data"} was returned in response to the request... which seems good. However, the way that the JSONP callback works, it generates its own script to do the calling and fetching and interpreting of the incoming JSON. In this case, it interprets the JSON to need a label which it does not have, thus an error is thrown "invalid label" ... there must be some way to hack things to just deliver the JSON, but the whole required use of JSONP callbacks suggests that the server configuration is wrong, right? Or why does it work without JSONP for IIS7 and not IIS6?


Despite my not liking the callback JSONP solution, it appears to work ok. The error is still returned about an invalid label, but that does not appear to stop the remaining javascript from running... and so the application is working with IIS6 now. I have not tested the fix of using the callbacks and JSONP against IIS7 yet, but I expect it will work well enough.


Here is a link to the discussion that lead me to my current solution. I do still hope to find a more elegant solution, however.

NeoWin.net

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

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

发布评论

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

评论(1

半岛未凉 2024-10-25 10:58:30

您确定您的应用程序扩展映射设置正确吗?

请关注本文在 IIS6 上运行 MVC2 并确保已完成所有不同的配置,这可能是进一步研究细节之前的第一步。

我真的倾向于相信它与 HTTP 动词有关。

Are you certain that your App Extension Mappings are set up correct?

Follow this article for running MVC2 on IIS6 and ensure all the different configurations have been done, that's probably the first step before going further and investigating specifics.

I'm really inclined to believe it's related to HTTP Verbs.

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