JQuery POST 请求转换为 OPTIONS。为什么?
我明确指定了 POST,但在请求中没有看到发布数据,而且还指定它有一个 OPTIONS。
响应应该是 HTML,以表格格式指定与查询匹配的用户。 我正在尝试发布并阅读 html 以创建自动完成输入框。
这是 Jquery 代码:
$.post('https://internal.company.com/data/displayUserList',
{ Email: "", Name: "%GEORGE%"},
function(responseText, textStatus) {
console.log("Response:\n" + responseText + textStatus)
}
);
FireBug1.6.1 (Firefox) 捕获的请求
OPTIONS /data/displayUserList HTTP/1.1
Host: internal.company.com
User-Agent: Mozilla/5.0 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Origin: null
Access-Control-Request-Method: POST
I explicitly specify a POST and I don't see the post data in the Request and more over specifies it has a OPTIONS.
The response should be a HTML specifying matching users to Query in table format.
I am trying to post and read the html to create a auto-complete input box.
This the Jquery Code:
$.post('https://internal.company.com/data/displayUserList',
{ Email: "", Name: "%GEORGE%"},
function(responseText, textStatus) {
console.log("Response:\n" + responseText + textStatus)
}
);
Request captured by FireBug1.6.1 (Firefox)
OPTIONS /data/displayUserList HTTP/1.1
Host: internal.company.com
User-Agent: Mozilla/5.0 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Origin: null
Access-Control-Request-Method: POST
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您违反同源政策限制,则可能会发生这种情况。
Access-Control-Request-Method
请求标头让我认为情况就是如此。我发现您在发布请求中指定了完整地址https://internal.company.com/data/displayUserList
。确保托管此脚本的页面也源自https://internal.company.com
。最好是使用相对地址:This could happen if you violate the same origin policy restriction. The
Access-Control-Request-Method
request header makes me think this is the case. I see that you specify a full addresshttps://internal.company.com/data/displayUserList
in your post request. Make sure that the page hosting this script is originating fromhttps://internal.company.com
as well. The best would be to use a relative address:如果您尝试调用另一个域中的不同服务器,那么解决这个问题的策略应该驻留在后端,以使服务器允许来自不同前端域的调用,在这种情况下,您不应该试图打破你的头在前端调整这个。
if you are trying to call a different server in another domain then the strategy to overcome this should reside in the backend to make the server to allow calls from a different front-end domain and in that case you shouldn't break your head trying to adjust this in the front end.