Got this in Chrome dev console:
Font from origin 'http://cdnjs.cloudflare.com' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://xx.xx.xx.xx:8000' is therefore not allowed
access.
However, I did this:
curl -I http://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.2.0/fonts/fontawesome-webfont.ttf?v=4.2.0
HTTP/1.1 200 OK
Date: Thu, 11 Dec 2014 15:51:47 GMT
Content-Type: application/font-sfnt
Content-Length: 112160
Connection: keep-alive
Last-Modified: Thu, 28 Aug 2014 04:30:29 GMT
Expires: Tue, 01 Dec 2015 15:51:47 GMT
Cache-Control: public, max-age=30672000
Access-Control-Allow-Origin: *
So what's going on??
EDITED
Oh never mind, I resolved it by using https: instead of just // ..
I resolved it by using https: instead of just // ..
Related
I'm trying to use the google drive API using a device_code from the Google API. In the documentation, the Google Drive scope doesn't seem to be listed:
https://developers.google.com/identity/protocols/OAuth2ForDevices#allowedscopes
However, in the exact same page, they have an example that uses the Google Drive API in the https://developers.google.com/identity/protocols/OAuth2ForDevices#callinganapi
When I try connecting using any google Drive scope, with the following request:
POST /o/oauth2/device/code HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: accounts.google.com
Connection: close
User-Agent: Paw/3.1 (Macintosh; OS X/10.12.4) GCDHTTPRequest
Content-Length: 136
client_id=clientid&scope=https://www.googleapis.com/auth/drive.readonly
I get this answer:
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Tue, 23 May 2017 03:02:31 GMT
Server: ESF
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: quic=":443"; ma=2592000; v="37,36,35"
Accept-Ranges: none
Vary: Accept-Encoding
Connection: Close
{
"error" : "invalid_scope"
}
I'm just wandering since there is a difference in the documentation if it is or isn't possible to do it, if I made a mistake or not.
Having had repeatedly no joy with accessing groups settings via UrlFetch in GoogleAppsScript I looked to test the basic query I was using according to the docs in the APIs Explorer
UrlFetchApp.fetch('https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?key={YOUR_API_KEY}', fetchArgs);
Never completes a round tring
The fact that the APIs explorer also fails with similar errors at least gives me some comfort, but where to report the failing?
GET https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?key={YOUR_API_KEY}
Authorization: Bearer ya29....[snip]
X-JavaScript-User-Agent: Google APIs Explorer
gives
200 OK
cache-control: private, max-age=0, must-revalidate, no-transform
content-encoding: gzip
content-length: 731
content-type: application/atom+xml; charset=UTF-8
date: Tue, 12 Nov 2013 11:31:09 GMT
etag: "N…[snip]…I"
expires: Tue, 12 Nov 2013 11:31:09 GMT
server: GSE
[application/atom+xml; charset=UTF-8 data]
adding any field to the query
GET https://www.googleapis.com/groups/v1/groups/exampleGroupId#example.com?fields=archiveOnly&key={YOUR_API_KEY}
Authorization: Bearer ya29....[snip]
X-JavaScript-User-Agent: Google APIs Explorer
always results in error
400 Bad Request
cache-control: private, max-age=0
content-encoding: gzip
content-length: 209
content-type: application/vnd.google.gdata.error+xml; charset=UTF-8
date: Tue, 12 Nov 2013 11:33:34 GMT
expires: Tue, 12 Nov 2013 11:33:34 GMT
server: GSE
[application/vnd.google.gdata.error+xml; charset=UTF-8 data]
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="http://schemas.google.com/g/2005">
<error>
<domain>GData</domain>
<code>invalidParameter</code>
<location type="parameter">fields</location>
<internalReason>Invalid field selection archiveOnly</internalReason>
</error>
</errors>
Is the API borked?
Try using the Google OAuth 2.0 Playground instead. I think the Groups Settings API Explorer is broken.
I am also having trouble with implementing with in Apps Script. I am stuck in an authorization loop. Similar to this reported bug. https://code.google.com/p/google-apps-script-issues/issues/detail?id=3046
This one works:
view-source:http://code.jquery.com/jquery-2.0.3.min.js
This one does not:
view-source:http://pagead2.googlesyndication.com/pagead/show_ads.js
The network status is "canceled". Response headers:
HTTP/1.1 200 OK
P3P: policyref="http://www.googleadservices.com/pagead/p3p.xml", CP="NOI DEV PSA PSD IVA IVD OTP OUR OTR IND OTC"
Content-Type: text/javascript; charset=UTF-8
ETag: 18135184975683587730
Date: Thu, 11 Jul 2013 10:00:44 GMT
Expires: Thu, 11 Jul 2013 11:00:44 GMT
X-Content-Type-Options: nosniff
Content-Disposition: attachment
Content-Encoding: gzip
Server: cafe
Content-Length: 6489
X-XSS-Protection: 1; mode=block
Age: 2014
Cache-Control: public, max-age=3600
Without "view-source" I'm able to download the file and view the source but I want to know why this happens.
A strange thing in addition is, that it is not possible to open the web delevoper tools after opening this view-source url. If you do, the tools are completely blank:
I'm taking a guess here: it has to do with the Content-Disposition setting in the Response Header.
Reference: http://support.microsoft.com/kb/260519.
Google Drive should be able to serve html according to this blogpost: http://googleappsdeveloper.blogspot.nl/2012/11/announcing-google-drive-site-publishing.html
But on my account I just get my html code between <pre></pre>.
I created a test folder with a test html file: https://googledrive.com/host/0BxVNvXP_dI5QTEstTEtmMXNkOFU/
Contents of the html file:
<html>
<head>
<title>Test 123</title>
</head>
<body>
Test 123.
</body>
</html>
The example in the blog post has the following HTTP Response Headers:
HTTP/1.1 200 OK
status: 200 OK
version: HTTP/1.1
cache-control: private, max-age=315360000
content-length: 1724
content-type: text/html
date: Thu, 29 Nov 2012 12:55:22 GMT
last-modified: Tue, 06 Nov 2012 23:57:41 GMT
server: HTTP Upload Server Built on Nov 21 2012 16:10:52 (1353543052)
My page has the following HTTP Response Headers:
HTTP/1.1 200 OK
status: 200 OK
version: HTTP/1.1
cache-control: private, max-age=315360000
content-length: 96
content-type: text/plain
date: Thu, 29 Nov 2012 12:51:00 GMT
last-modified: Thu, 29 Nov 2012 12:50:28 GMT
server: HTTP Upload Server Built on Nov 21 2012 16:10:52 (1353543052)
The difference thus is the content-type header. Somehow I need to tell Google Drive my html is indeed an html. file.
The MIME type for a file is set at upload time. Did you maybe upload the file with a .txt extension and rename it? If you delete and re-upload the HTML file I bet it will work.
Most web pages are normally parsed and of course I don't see tags like <html> or <a href=>.
But, when I open some web sites, the source code pops up.
Try this
http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
So I saved this web page and reopened locally using firefox, everything seems normal again.
any reasons?
You're viewing the file in an SVN repository browser. They must have the encoding for the documents in these directories set to render as plain text. I am using chrome and saw the same thing. It's by design in this case.
As everybody says, it is the server side (Apache) configuration. You can confirm this by issuing HEAD request.
curl -I http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
returns
HTTP/1.1 200 OK
Date: Thu, 29 Dec 2011 00:27:49 GMT
Server: Apache
Last-Modified: Thu, 16 Oct 2008 18:13:57 GMT
ETag: "2//jes/JESHelp/auxHelp/mediaToolsOverview.html"
Accept-Ranges: bytes
Expires: Thu, 29 Dec 2011 00:30:49 GMT
Content-Length: 1802
Content-Type: text/plain
Cache-Control: public, max-age=180
Age: 0
Notice that Content-Type says "text/plain"
You're looking at a svn repository, and the response type is text/plain instead of text/html, so the browser renders it as text instead of html
SVN or not the important for the browser is the header Content-Type - the most of the pages are rendered as html, no matter the extension or absence of such, because of the header. Another effect obviously will be that JavaScript won't be executed.
About the Content-Type ietf and MIME types list Wikipedia
Header Content-Type: text/html; charset=utf-8 - rendered
lynx -head -dump http://stackoverflow.com/questions/8662745/why-do-i-see-the-source-code-html-of-some-web-pages
HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Length: 41163
Content-Type: text/html; charset=utf-8
Expires: Thu, 29 Dec 2011 00:26:08 GMT
Last-Modified: Thu, 29 Dec 2011 00:25:08 GMT
Vary: *
Date: Thu, 29 Dec 2011 00:25:08 GMT
Connection: close
Header Content-Type: text/plain - displayed as text
lynx -head -dump http://mediacomp-jes.googlecode.com/svn-history/r68/jes/JESHelp/auxHelp/mediaToolsOverview.html
HTTP/1.0 200 OK
Date: Thu, 29 Dec 2011 00:26:00 GMT
Server: Apache
Last-Modified: Thu, 16 Oct 2008 18:13:57 GMT
ETag: "2//jes/JESHelp/auxHelp/mediaToolsOverview.html"
Accept-Ranges: bytes
Expires: Thu, 29 Dec 2011 00:29:00 GMT
Content-Length: 1802
Content-Type: text/plain
Cache-Control: public, max-age=180
Age: 0
This is because this page has been encoded and then put in the page. So if you look at the page source your see it is written like <html> <head> <title> obviously because some one wants to show the page mark up. Nothing wrong with your browser etc