Hi my problem is a bit wired:
my $.ajax success handler looks like:
function(data){
alert(data);
}
Pretty simple, yeah?
The problem is that data IS ALWAYS 3 character long - no matter what was sent by the server! The characters: 31 65535 8 (using charCodeAt()).
In other browsers (even in IE 8) all works fine.
I've looked at xhr.responseText in complete handler - just the same result.
UPDATE
Full http response
HTTP/1.1 200 OK
Date: Sun, 07 Feb 2010 13:35:39 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.2.10-2ubuntu6.4
Set-Cookie: 1111111111111111=UjVXb1Q3WTdUIQ8jXmALbA88VzpRcVcgBzMDcldyUmtWawAyAFpQP1IwASEAbFh%2FDjoLZ1RiBWlWdwBnUGMHZlU2UGBTZFA5B2UMMlJgC29SbVdjVDRZOVRsDzReaQtuDzpXZVFjV2UHYwM1VzNSNlYzAG4AMVAwUjUBIQBsWH8OOgtlVGAFaVZ3AD5QIgdcVWVQNlNhUHIHMAwjUiQLL1JvVyZUOVk8VGkPal54C2wPNVcyUX1XYgdgAzlXL1IzVioAbQA3UG9SdgE4ACRYNg4xC2RUagVxViAAJFA3B3FVW1AzU2JQZQc7DCRSdQs2UidXb1Q2WT1UYA9yXhcLMg92V2lRP1c%2FBzcDLlc1UixWNAB8AC1QNVI7AW4AJ1htDnQLPVQyBT9WMABsUHIHTlVXUBtTQFAgB20MflJnCzZSdFcCVGpZY1Q%2BDz9eLQsuDyxXTlEHV3MHYAMvVzBSOVYmAGcAdlBsUmUBMABtWC4ObAs1VCMFJ1YKADZQMQd3VW1QJFNsUHQHLAxyUmwLflJuV2RUM1k3VHgPYV5oC2sPOVc1UWdXagdgAzBXOVIgVj8AIQ%3D%3D; expires=Tue, 07-Feb-2012 13:35:39 GMT; path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 21
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
1
UPDATE !
Well, problem temporary? solved by disabling gzip in .htaccess
The characters you get look weird, but could it be that it's a BOM? It's none of the ones listed in the article, but maybe getCharCode() gets something wrong.
In that case, you would have to check the script you call to request the data. Try saving it explicitly without a BOM.
this is most times an problem with propper encoding of the requested content / displayed content.
Please verify that both use the same format.
Despite ajax is always done in UTF-8 some implementations are weird and they don't allow passing non ascii characters. You have to change them to entities.
If You pass only one character and still get problems - It might be the BOM mentioned by Pekka. You would have to save Your PHP FILE without any spaces before
Second thing is that You might be outputing something at the end of the php file.
Related
Using JavaScript, I'm calling a rest API that returns the following headers:
Cache-Control:max-age=60
Content-Length:20
Content-Type:application/json; charset=utf-8
Date:Mon, 15 Aug 2016 21:01:56 GMT
Server:Microsoft-IIS/10.0
Vary:Accept-Language
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET
This get cached by Chrome/Firefox/Safari correctly on subsequent calls, but in Edge nothing gets cached. If I stop sending the Vary:Accept-Language header, then it gets cached, but the result is that if a different language is passed to Accept-Language then it returns the (wrong) cached content.
Am I missing something to make Edge cache it?
I have generated the following code using srihash.org for URL https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js:
<script src="https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js"
integrity="sha384-CAN0Iz/H09oATWPeJZclEOAM/nF1cq3DSuAbxi9IMbZIx8m3ERInrpuk11n+lHRq"
crossorigin="anonymous"></script>
When trying to load the page that contains the integrity-checked script, I get the following error in Chrome 50 on Windows:
Failed to find a valid digest in the 'integrity' attribute for
resource 'https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js'
with computed SHA-256 integrity
'vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU='. The resource has been
blocked.
I also tried to generate the hash manually (again, on Windows, openssl-1.0.2h), using:
openssl dgst -sha384 -binary Cesium.js | openssl base64 -A
resulting in:
X5EHALkqk8r9hyCKwav7y+6BOUg2dRH90/qSxdytan2SQQB9g8jsYYWLDKzNeKx4
This hash works when loading Cesium.js with Chrome. However, this raises the question which of the two hashes is correct... Leaving out the unlikely possibility of a MITM-attack, I assume it has something to do with line endings or encoding. Cesium.js seems to have Windows line endings, and the HTTP response of loading it in Chrome is attached below.
How can the difference between the two hashes be explained, and which one is correct?
HTTP response headers for Cesium.js:
HTTP/1.1 200 OK
Cache-Control: max-age=172800
Content-Length: 494091
Content-Type: application/javascript
Content-Encoding: gzip
Last-Modified: Mon, 02 May 2016 15:12:32 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/8.5
x-amz-id-2: giU2DeYQi87OAkuyr2qKeZx8KRihIY7TV9qcJShi/YVl+C5K50mHeSLFWYhA8k5Oc+A50Oxjh/4=
x-amz-request-id: 112881D9D52248F6
X-Powered-By: ARR/3.0
X-UA-Compatible: IE=edge
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,X-Requested-With
Date: Mon, 30 May 2016 12:49:46 GMT
After some digging, I found out that the hash generated by srihash.org is incorrect.
The incorrect result is due to the combination of two factors:
Cesium.js from cesiumjs.org is always served with Content-Encoding: gzip, even if the request does not contain Accept-Encoding: gzip.
srihash.org (see source) uses xhr2 to fetch resources, which does not support gzip encoding.
As you suspected, this is apparently a chrome bug related to encoding. Other people report the issue for other scripts.
Check out this bug page on inconsistencies between chrome and openssl.
As a temporary workaround, I'd add
vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=
to your trusted SHA256 integrity attributes (after having verified the downloaded script is actually the right one).
Chrome is probably computing this hash before the unzip, of with a special encoding.
I am actually getting an Ajax Response Text from a PHP Server. Suppose the response text comprises of 20 characters.
(e.g. echo "asdhfgyd dhrjtjsjtjr";)
This equals roughly (20/1024) KB.
I'm using a mobile web application to get this reponse text using standard Ajax XMLHttpRequest. However when i measure the data usage by the mobile app due to only that one single ajax response text, it uses nearly 3 KB. This is what i'm not understanding, what is causing this additional data usage, can you please help me out on this.
Additionaly: I confirm that this is the only part of the app that makes internet usage, the others are offline features.
The data you see in the response text is only the body of the response. The other bytes will most likely have been taken up by the headers.
For example here is a response I would expect to receive when calling an API:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?XFxwc2ZcSG9tZVxEb2N1bWVudHNcR2l0SHViXFNvdXJjZVxDaGVyaXNoQXF00XJpc2guQXBpXGFwaVxjaGlsZFxsaXN0?=
X-Powered-By: ASP.NET
Date: Fri, 13 Mar 2015 09:02:35 GMT
Content-Length: 577
[{"result":"FooBar"}]
I'm using backbone.js to build a web site. It runs fine in our development server, but it didn't parse data in client's server using IE7-9. (Firefox, Safari are fine)
I found that backbone call fetch() to request data, but it don't start parse() when data return. I can't find success or error return. There is a part of code:
EMR.CategoriesCollection = Backbone.Collection.extend({
url : 'contents/json/categories.txt',
initialize:function () {
console.log('Get data from:', this.url);
this.fetch();
},
model: EMR.ItemModel,
parse : function(data) {
console.log("CategoriesCollection parse data:", [data]);
return data;
}
});
Please compare two links below ( in IE 7-9 ), they are same set of code, just server difference:
It works:
1) http://pms.dq.hk/clients/amex_eMR/client/cn/emr/test_data.html
It fail:
2) http://qwww.americanexpress.com/hk/cn/emr/test_data.html
If backbone sent fetch(), but parse() didn't trigger, how to trace the issue?
Any possible ways I can try?
Thanks for your suggestion.
Regards,
Michael
the only differences between the two that I can see are the response headers..
your server:
Connection Keep-Alive
Date Thu, 31 May 2012 03:41:16 GMT
Etag "ae6691-123ac-59de3b00"
Keep-Alive timeout=15, max=98
Server Apache/2.0.63 (Unix) PHP/5.3.2 DAV/2
client server:
Connection keep-alive
Content-Type text/plain; charset=big-5
Date Thu, 31 May 2012 03:41:25 GMT
Last-Modified Tue, 22 May 2012 06:41:10 GMT
Vary Accept-Encoding
the content-type in the client server response caught my eye, but I'm no IE expert.. you might want to mention what version of IE you're having issues with and test some other versions to isolate it..
Any possible ways I can try?
Hello. Did you try to add a error callback to the fetch method?
Also, the «fail» server send gzipped content in gzipped form. Maybe IE can't handle gzipped JSON in correct way? Or maybe you can try to change the Content-Type header from «text/plain» to «application/json»?
The problem is here:
http://forum.jquery.com/topic/the-problem-with-ie8-and-encoding-error-c00ce56e
Our client's server return data in
Content-Type text/plain; charset=big-5
When I added a error handler in fetch(), I can see a error return "Could not complete the operation due to error c00ce56e". It is the reason parse() doesn't work.
I can't change client's server setting, so I put the data file to other directory that returns Content-Type text/plain; to fix the problem.
(Note: This is a follow up to my question Can jQuery.getJSON put a domain's cookies in the header of the request it makes? and covers the XSS case of Setting a cookie in an AJAX request?)
I've been told I'm unable to set cookies to be read by other domains that are not subdomains of the current domain using $.cookie(..., ..., {domain: ...}). But in a comment on a response to my last question, #zanlok said "The server's reply, however, can definitely set a cookie" and it got two upvotes.
So I thought I'd try using a service which was created for the explicit purpose of setting cookies called Freebase's "touch" API. The call looks like:
$.getJSON("http://api.sandbox-freebase.com/api/service/touch",
{}, // URL parameters
afterCookieIsSetCallback); // Callback function
Looking in FireBug at the response header it's like this:
Date Wed, 24 Nov 2010 03:35:28 GMT
Server Apache
X-Metaweb-Cost [...]
Etag [...]
Expires Wed, 24 Nov 2010 03:35:29 GMT
Cache-Control no-store
Vary Accept-Encoding
Content-Encoding gzip
Set-Cookie mwLastWriteTime=1290569730|10325_9202a8c04000641f80000000199eff96|sandbox; expires=Thu, 25-Nov-2010 03:35:28 GMT; Path=/
Last-Modified Wed, 24 Nov 2010 03:35:28 GMT
Content-Length 134
Content-Type text/plain; charset=utf-8
X-Cache MISS from cache01.sandbox.sjc1.metaweb.com
Connection keep-alive
X-Metaweb-TID cache;cache01.sandbox.sjc1:8101;2010-11-24T03:35:28Z;0001
So there's definitely a Set-Cookie in there, and the script runs the response handler. Yet the cookie is not present in the request headers for later JSON requests this script makes to .sandbox-freebase.com.
(By contrast, simply typing the touch api URL into the address bar and loading it that way does set the cookie for future requests. That applies even in other tabs.)
This seems to be a deviation from a prior "expected behavior", because there was a toolkit published by MetaWeb circa "2007-2009" which seemed to think such an approach could work:
http://www.google.com/codesearch/p?hl=en#v099O4eZ5cA/trunk/src/freebase/api.js&q=touch%20package:http://mjt%5C.googlecode%5C.com&l=340
Without knowing much about it, I'm wondering if it was a recent change that Firefox adopted and then WebKit followed suit. Perhaps the one mentioned here:
http://trac.webkit.org/browser/trunk/WebCore/xml/XMLHttpRequest.cpp#L856
So is there any canonical documentation on this particular issue?
The AJAX call you are making, is making a request to a domain outside of the domain of the top level url(the url in the address bar). This results in it being a 3rd party cookie, by default Internet explorer won't persist a 3rd party cookie. Meaning that the cookie will come back in the Set-Cookie header on the first request, but subsequent requests that you make to that server will not have that cookie sent in the request.
Like you said, if you go directly to the url in your browser it works. This is because in this case it's a first party cookie.
In order for IE to accept 3rd party cookie's the server that is sending the SET-COOKIE header on it's response, must also have a P3P Policy Header set.
Here is an example, when you navigate to CNN, you will notice one of the requests it makes is to a domain name of b.scorecardresearch.com, scorecardresearch is dropping a tracking cookie, but this cookie is considered a 3rd party cookie. So in order to make it work they had to also in include a p3p header, see headers below:
HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Date: Thu, 02 Dec 2010 19:57:16 GMT
Connection: keep-alive
Set-Cookie: UID=133a68a4-63.217.184.91-1288107038; expires=Sat, 01-Dec-2012 19:57:16 GMT; path=/; domain=.scorecardresearch.com
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, no-cache, no-cache=Set-Cookie, no-store, proxy-revalidate
Server: CS
If you were to copy this header and add it to the response, you would notice that the cookie's start working,
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
It's best that you craft a P3P header specific for your business, but the above should work for testing purposes.
If I correctly understand you, you are wondering why the server sends Set-Cookie only on the first request. If that is true, then it's by design - take a look here:
http://en.wikipedia.org/wiki/HTTP_cookie
Set-Cookie is like a setter - the server sends it for the browser to cache it locally. It can send every time, but there is no need to do that, so it will send it again only if it needs to change the value stored locally.
Browser, on the other hand, will send Cookie header every time with the contents set by the last issued Set-Cookie from the server.