All of a sudden, chrome (v 23.0) began rendering .txt files used to debug curl http requests. There is javascript and html in these files that used to be displayed as text. Now, some of the javascript is causing a redirect. Safari and Firefox are still working as before.
I'm concluding that this is a setting, but did not find any thing related in Chrome settings.
Any ideas where to change a setting like this.
Edit: HTTP Headers:
Request URL:https://mysite.com/debug/checkin_cron/checkin_cron_bu_913.txt
Request Method:GET
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:
Host:mysite.com
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
Response Headers
Accept-Ranges:bytes
Connection:Keep-Alive
Content-Length:47520
Content-Type:text/plain
Date:Fri, 14 Dec 2012 23:09:00 GMT
Keep-Alive:timeout=3, max=100
Last-Modified:Fri, 14 Dec 2012 22:28:31 GMT
Server:Apache
Related
I am working on a JavaScript application, where I want to read data from an XML file and post them into a HTML file.
My code is producing the following error:
Request URL:http://myServer/dirs/dir/scripts/xml_data.xml
Request Method:POST
Status Code:405 Method Not Allowed
Request Headersview source
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en,en-US;q=0.8,da;q=0.6
Connection:keep-alive
Content-Length:13
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Host:myServer
Origin:http://myServer
Referer:http://myServer/dirs/dir/inWork.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36
X-Requested-With:XMLHttpRequest
Form Dataview sourceview URL encoded
node:xnode-24
Response Headersview source
Allow:GET, HEAD, OPTIONS, TRACE
Cache-Control:private
Content-Length:5309
Content-Type:text/html; charset=utf-8
Date:Thu, 12 Feb 2015 21:06:08 GMT
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET
Based on this posting I created a new 'Handler Mapping' and I also adjusted the 'Handler Mapping' for 'StaticFile' to allow the methods: GET,HEAD,POST,DEBUG,PUT,DELETE.
The IIS server was restarted but still the error message appears and the only methods allowed are: GET, HEAD, OPTIONS, TRACE.
So, there is some configuration file or 'Handler Mapping' overriding my settings, or I simply did not consider.
Any suggestions on how to tell the IIS to accept my settings for this XMLHttpRequest?
I'm seeing some interesting Chrome behaviour, and I need a hand deciphering what's going on and possibly how to work around it effectively.
Here's the scenario:
User views a list of resources (e.g. TODO items)
User modifies a few of them
User navigates away from my Ember application and then returns via the back button
User sees previous state of resources
When making the initial request for the resources, I'm seeing something like this coming from the browser:
Request
Request Method:GET
Request URL:https://api.server/some_resource?ids%5B%5D=7495&ids%5B%5D=6420&ids%5B%5D=6787...
Status Code:200 OK
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate
Accept-Language:en-US,en;q=0.8
If-None-Match:"(some md5)"
Referer:https://api.server
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2121.3 Safari/537.36
X-Requested-With:XMLHttpRequest
Response
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Referer,Accept,Content-Type,Authorization
Access-Control-Allow-Methods:GET, POST, PUT, OPTIONS
Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:application/json; charset=utf-8
Date:Tue, 12 Aug 2014 14:53:06 GMT
ETag:"(some md5 not matching If-None-Match)"
Server:nginx
Status:200 OK
Strict-Transport-Security:max-age=31536000
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:64b7607a-20a8-46f1-906e-0568bffffd15
And the subsequent request when returning to view the resources:
Request
Request Method:GET
Request URL:https://api.server/some_resource?ids%5B%5D=7495&ids%5B%5D=6420&ids%5B%5D=6787...
Status Code:200 OK (from cache)
Accept:application/json, text/javascript, */*; q=0.01
Referer:https://api.server
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2121.3 Safari/537.36
X-Requested-With:XMLHttpRequest
Response
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Referer,Accept,Content-Type,Authorization
Access-Control-Allow-Methods:GET, POST, PUT, OPTIONS
Cache-Control:max-age=0, private, must-revalidate
Content-Encoding:gzip
Content-Type:application/json; charset=utf-8
Date:Tue, 12 Aug 2014 14:53:06 GMT
ETag:"(same md5 as above for initial request)"
Server:nginx
Status:200 OK
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:64b7607a-20a8-46f1-906e-0568bffffd15
X-Runtime:0.160730
Notice on the subsequent request that Chrome is reporting the status as "200 OK (from cache)", which seems to be why I'm seeing this happen.
My homework on this problem has turned up a seemingly related question on SO, which in turn links to You Do Not Understand Browser History. OK, so Chrome isn't validating the etag when the back button is used. How do I work around this? Disabling caching of requests really sucks, and it seems like there should be a more elegant solution.
My app needs to access a resources as in the Request URL however I can see in the Chrome network console that the request is GET (Cancelled)
Request URL:http://localhost:6001/_api/
Request Headers CAUTION: Provisional headers are shown.
Accept:application/json, text/javascript, */*; q=0.01
Cache-Control:max-age=0
Origin:http://127.0.0.1:6001
Referer:http://127.0.0.1:6001/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/33.0.1750.152 Chrome/33.0.1750.152 Safari/537.36
Is there anything wrong in the request? If I access the Request URL and paste it in the browser, the JSON string is returned properly. What could be the reason?
Update:
Prior to the request above here there is a request for this:
Request URL:http://localhost:6001/_api/_session
Request Method:OPTIONS
Status Code:200 OK
Request Headersview source
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:accept
Access-Control-Request-Method:DELETE
Cache-Control:max-age=0
Connection:keep-alive
Host:localhost:6001
Origin:http://127.0.0.1:6001
Referer:http://127.0.0.1:6001/
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/33.0.1750.152 Chrome/33.0.1750.152 Safari/537.36
Response Headersview source
access-control-allow-headers:Authorization, Content-Type, If-None-Match
access-control-allow-methods:GET, HEAD, POST, PUT, DELETE, OPTIONS
access-control-allow-origin:*
access-control-expose-headers:WWW-Authenticate, Server-Authorization
access-control-max-age:86400
cache-control:no-cache
Connection:keep-alive
content-encoding:gzip
content-type:application/json; charset=utf-8
Date:Sun, 06 Apr 2014 04:26:37 GMT
Transfer-Encoding:chunked
vary:accept-encoding
But the status was: A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://127.0.0.1:6001' is therefore not allowed access.
You are mixing 127.0.0.1 and localhost which could make it look like xss. Use one or the other but not both.
We have an SPA that draws more javascript modules from a separate backend server, assisted by Require.js. By nature of the XHR loading procedure, pre-flight OPTIONS requests are made to the backend server and the Access-Control-Allow-Origin response is perfectly valid. The process of login and initial module loading work just fine, as expected.
XHR finished loading: "http://backend.cloudapp.net/api/modules/resourceA".
XHR finished loading: "http://backend.cloudapp.net/api/modules/resourceB".
Funny thing is, certain subsequent actions that call for more modules would unexpectedly raise a CORS error in Chrome.
XMLHttpRequest cannot load
http://backend.cloudapp.net/api/modules/resourceC. Origin
https://frontend.cloudapp.net is not allowed by
Access-Control-Allow-Origin.
Which does not make sense, since the previous modules loaded just fine. Even the actual OPTIONS preflight came back proper for resourceC. Some other places in the UI have their modules loading fine too. And Firefox does not appear to suffer from this problem. Has anybody experienced similar CORS errors?
Request/response headers for successful (expected) module
Request URL:http://backend.cloudapp.net/api/modules/resourceA
Request Method:OPTIONS
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:accept, origin, content-type
Access-Control-Request-Method:GET
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Headers:accept, origin, content-type
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:0
Date:Wed, 19 Jun 2013 07:12:42 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request URL:http://backend.cloudapp.net/api/modules/resourceA
Request Method:GET
Status Code:200 OK
Request Headers
Accept:application/json
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Content-Type:application/json
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:5048
Content-Type:application/json; charset=utf-8
Date:Wed, 19 Jun 2013 07:12:42 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request/response headers for unsuccessful module
Request URL:http://backend.cloudapp.net/api/modules/resourceC
Request Method:OPTIONS
Status Code:200 OK
Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:accept, origin, content-type
Access-Control-Request-Method:GET
Host:backend.cloudapp.net
Origin:https://frontend.cloudapp.net
Proxy-Connection:keep-alive
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
Response Headers
Access-Control-Allow-Headers:accept, origin, content-type
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:https://frontend.cloudapp.net
Cache-Control:no-cache
Connection:Keep-Alive
Content-Length:0
Date:Wed, 19 Jun 2013 07:12:59 GMT
Expires:-1
Pragma:no-cache
Proxy-Connection:Keep-Alive
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
Request URL:http://backend.cloudapp.net/api/modules/resourceC
Request Headers
Accept:application/json
Content-Type:application/json
Origin:https://frontend.cloudapp.net
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36
(And browser blocks further action)
Given that Chrome has gone through so many version updates, in addition to us deploying some module resources in a different package manner now in different AWS infrastructure, we no longer experience this problem now.
Inspired from my answer here
It might be worth investigating if any of the failing XHRs are sending any peculiar unicode character. In our case, one of our user's name contained a unicode character and our HTTP proxy wasn't handling it properly thereby leading to a CORS error.
On the site I'm currently working on, we use html5 video with h.264. If it's not available we use a flash fallback. The flash fallback is working just fine in both chrome 23 and 24, but the html5 video only works in chrome 23.
I opened the video file in it's own tab (which chrome then has a simple bootstrap snippet of html to play it) in each version of chrome and saved the request and response information. It makes three requests actually but I find teh first one to be the most interesting. Here is the header information for the request and response for both.
Chrome 23:
Request:
URL:http://localhost:8040/media/preview/ab0eca40ffee4f/c268a6240b08ff/MP4_360
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Cookie:beaker.session.id=c59137ff184428045f317d6b2385aa384 4c30f
Host:localhost:8040
Pragma:no-cache
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
-------------------------------
Response Headersview source
Accept-Ranges:bytes
Content-Disposition:inline; filename="2af3dc86e4fae33370c268a6240b08ff"
Content-Length:5817287
Content-Type:video/mp4
Date:Wed, 06 Feb 2013 15:51:25 GMT
Last-Modified:Fri, 07 Dec 2012 19:47:51 GMT
Server:CherryPy/3.2.0
Chrome 24:
Request URL:http://localhost:8040/media/preview/ef5a0220219b8e0/a4fe5f21c26f/MP4_360
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:beaker.session.id=5c080dc2b3343dc725ea368dae30cb1bc324
Host:localhost:8040
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
-----------------------------------
Response Headersview source
Accept-Ranges:bytes
Content-Disposition:inline; filename="e10cce5997514651851aa4fe5f21c26f"
Content-Length:3632612
Content-Type:video/mp4
Date:Wed, 06 Feb 2013 18:45:04 GMT
Last-Modified:Tue, 05 Feb 2013 20:15:20 GMT
Server:CherryPy/3.2.0
Has anyone else expierenced this? I'm willing to do further tests as requested as well.
You may fix this problem by doing the following:
There is an option in chrome://flags called "Disable hardware-accelerated video decode" enable it.
https://productforums.google.com/forum/?fromgroups=#!searchin/chrome/mp4/chrome/ilqhiTTZcaY/hkPGA3GK6BIJ
And this is a bug filed three weeks ago: http://src.chromium.org/viewvc/chrome?view=rev&revision=178906. According to its status it is “Fixed”. However, later on in the comments it is saying the fix might be pushed for version M25 and is fixed with version 26.0.1395.1.
As a test, I have downloaded version 26 of Chrome (the developer version), (re)disabled the “Disable hardware-accelerated video decode”, and everything works fine. If you want to do the same, visit Chrome’s release page and choose “Dev channel for Windows”.