访问相对URL的通过" AJAX"从"文件://"内容 [英] Accessing relative URL's via "ajax" from "file://" content

查看:223
本文介绍了访问相对URL的通过" AJAX"从"文件://"内容的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我整理一些演示页面,我想证明一件事涉及到取HTML片段动态地后续处理。因此,我有简单的jQuery code是这样的:

I'm putting together some demo pages, and one of the things I want to demonstrate involves fetching HTML fragments dynamically with subsequent processing. Thus I've got simple jQuery code like this:

$('#target').load('./content_fragment.html', function() {
  $(this).doSomething();
});

我做的这一切都源自文件:// URL的链接,因为整个事情是一个presentation我(可能)从拇指驱动器或运行的东西的一部分。因此,content_fragment.html只是另一个本地文件,就像包含code主页。

I'm doing all this from file:// URLs because the whole thing is part of a presentation that I (might) run from a thumb drive or something. Thus, "content_fragment.html" is just another local file, just like the main page that contains that code.

现在这一切都从Firefox或Safari工作得很好,和的使用相对网址在浏览器正常工作(iframe的SRC的网址,图片,脚本,CSS等),而Chrome刚不会注意那些.load()的要求的。如果我拉链拉上内容,并将其部署到Web服务器,然后得到它通过它的http:URL,那么Chrome浏览器工作正常。当它不工作,我没有看到在Chrome控制台中的任何错误;它只是不获取内容。我试着用Chrome浏览器在Linux和XP,具有相同的结果。 (和Safari或Firefox到同一个文件:// URL始终做什么,我期待并加载内容)

Now this all works just fine from Firefox or Safari, and other uses of relative URLs work fine in Chrome (iframe "src" URLs, images, scripts, css, etc), but Chrome just won't pay attention to those ".load()" requests at all. If I zip up the content and deploy it to a web server, and then get at it via its "http:" URL, then Chrome works fine. When it doesn't work, I don't see any errors in the Chrome console; it just doesn't fetch the content. I've tried it with Chrome on Linux and XP, with identical results. (And Safari or Firefox to the same file:// URLs always do what I expect and load the content.)

所以我的问题是,这是古怪只是一个浏览器怪癖,或者是有什么本质上可疑的约XMLHtt prequests和文件://网址?换句话说,在Chrome浏览器做的右键的事情,这意味着其他浏览器都坏了?

So my question is, is this weirdness just a Chrome quirk, or is there something inherently questionable about XMLHttpRequests and file:// URLs? In other words, is Chrome doing the right thing, meaning the other browsers are broken?

推荐答案

您可以添加 - 让文件存取的档案到命令行启动时, Chrome浏览器禁用此安全功能:)

You can add --allow-file-access-from-files to the command line when launching chrome to disable this security feature :)

是不是一个错误?也许是,也许不是,所发生的事情是它不是治疗文件:// 作为一个单独的域,请求到不同的文件被视为一个不同的领域,因此阻止了< A HREF =htt​​p://en.wikipedia.org/wiki/Same_origin_policy> SOP规则的。它是由铬/铬开发商的选择,无论是正确的取决于你的观点,我想。

Is it a bug? Maybe, maybe not, what's happening is it's not treating file:// as a single domain, requests to a different file are treated as a different domain and therefore blocked by the SOP rules. It's a choice by the Chrome/Chromium developers, whether it's the correct one depends on your point of view I suppose.

有很多dicusssion对这个在Chrome发布在谷歌code节,你会发现感兴趣的讨论的此处这里

There's a lot of dicusssion on this in the Chrome issues section on Google code, you may find the discussion of interest, here and here.

这篇关于访问相对URL的通过&QUOT; AJAX&QUOT;从&QUOT;文件://&QUOT;内容的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆