I upgraded my Ember web application from ember 1.12.2 to 1.13.13 with ember-cli 0.2.7 and ember-data v1.13.16.
Now for some models the store.query('modelname', {'something': thus.get('id')} always gives old data in IE11. When I check the REST call in IE11 I also see 'from cache'. Why? In Chrome it does get the data from te server, NOT from the cache.
How can I tell in my Ember code it must NEVER get the data from cache?
You don't.
Well you could hack something together, but the right way to fix this is to specify the Cache-Control: no-cache header on the response.
The only way to solve this from the client is to add a unique id (like a timestamp) to every request so that every request seems unique. But why a hacky solution if the right path is clear?
Related
I am doing below code in Laravel 5.5 with mpdf 8.0
$mpdf = new \Mpdf\Mpdf();
$mpdf->WriteHTML('Hello World');
$mpdf->Output("test","I");
It outputs gibberish/garbage values, seemingly showing pdf file in raw form.
Some findings
If I use $mpdf->Output($reportPath, 'F'); (saving it to file) and the opening that. It opens the file as expected.
If I place die(); after $mpdf->Output("test","I"); it shows the document.
My suspicion is, it has something something to do with Content-type:application/pdf not being set by default but I have also tried using header("Content-type:application/pdf"); before Output but of no use. it is still showing Content-Type: text/html; charset=UTF-8 in response header in Network tab of chrome (also tried Firefox).
Some back-story
It used to work on php7.3 just fine, but I have to update it to php7.4 due to some library and multiple application on a single server scenario.
Also start using a sub-domain for my application instead of placing the directories after the domain.
I'm looking for
A solution that doesn't require me to place die; at the end of output.
Or some clue in on why this has started happening or/and perhaps why I need to place die; after Output.
Any other solution.
The goal is to provide some ref. for people encountering same issues in future, since I have spent hours and haven't anything that specifically address such issue.
Ok, so I found out that I can't just rely on $this->mpdf->Output('test.pdf',"I") to output my result (though it was working previously with the same line) to the browser.
Because for some reason it has started to send Content-Type:text/html value in Content-Type header so I had to change that.
Solution
I did it as below:
return response($this->mpdf->Output('test.pdf',"I"),200)->header('Content-Type','application/pdf');
We saw this issue on one of our dev machines - the vendor.js bundle in our Angular project had somehow gotten cached, while truncated, which breaks the web app until you clear the cache.
We do use browser caching (together with URL-hashing so caching doesn't prevent app updates).
Is there any way to prevent the browser from caching a truncated request? Actually, I would have thought that the browser has this built-in (i.e. it won't cache a request where the bytes header does not match the amount downloaded).
The browser where we reproduced the problem was Chrome.
I think I found the issue - for whatever reason, our HTTP Response was missing the "Content-Length" header in the Response Headers.
The response passes through 2 proxies so one of them might remove the "Content-Length" header.
What we did in such a case is to add a parameter for the request of a lib.
You just need to raise the number and next time the browser and the caches in between will fetch a new version from the server:
e.g. www.myserver.com/libs/vendor.js?t=12254565
www.myserver.com/libs/vendor.js?t=12254566
I'm using AFNetworking 2.0 to receive response from server. For first response, it works fine. However, after I change the data on the admin site, and verify that the change is made in a browser, then I run the app again, but I still get the previous response. I don't understand why? It seems that AFNetworking is caching the old response. I want to download the current feed. Who can help me, please????
I had the exact opposite problem. I was getting the same image from my server twice, AFNetworking wasn't caching. As I debugged it I realized that I was calling 2 slightly different URLs, in one case I was specifying an option that was the default on the server.
So this gave me the idea for a work around hack for you. It isn't the right answer but it should work. Just pass a useless parameter to the server. Change this parameter for each server call.
https://example.com/myrequest?index=0
then
https://example.com/myrequest?index=1
where index is the unused parameter.
Note: this is actually a pretty gross hack, it should get you running but you really should find the "correct" answer.
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.
I have 3 AJAX functions to move data between a Django app on my website and some JavaScript using YUI in the browser. There is not a major difference between them in terms of their structure, concept, code, etc. 2 of them work fine, but in the 3rd one, I get one spurious HTTP request immediately after the intended request. Its POST data contains a subset of the POST data of the intended request. The request meta data is identical except for the CONTENT_LENGTH (obviously) and the CONTENT_TYPE which is 'text/plain; charset=UTF-8' for the intended and 'application/x-www-form-urlencoded' for the unwanted request. I do not set the content type explicitely at all which seems to suggest both requests do not have the same origin and the second one just pops out of thin air.
The intended request sets HTTP_CACHE_CONTROL': 'no-cache' and 'HTTP_PRAGMA': 'no-cache', the spurious one does not. The dev server log output for both requests is
[15/Feb/2010 15:00:12] "POST /settings/ HTTP/1.1" 200 0
What does the last 0 at the end mean ? Could not find any documentation on that. This value is usually non-zero... In Apache, it is the total size in bytes of the server response, can someone confirm it's the same for Django ?
My problem obviously is to find out where this additional request comes from.
I am fairly familiar with JS debugging using Firebug and I think I'm good at Python and Django, but I do not know a lot about the internals of HTTP requests and responses. I can breakpoint and step through the JS code that sends the intended XMLHTTP request, but that breakpoint does not get hit again.
The problem occurs with both FF3 and Safari, I'm on Snow Leopard, so I can't test with IE or Chrome.
I've looked at Django debugging techniques and tools like http://robhudson.github.com/django-debug-toolbar/ but I think I already have the information they can give me.
Can someone advise on a strategy or a tool to narrow the problem down ?
The problematic AJAX function submits form data, the working two don't. Forms have a default action which takes place when the form is submitted: post a request with the form data. I failed to prevent this default action.
So the spurious request did indeed come out of the dark underwood of the browser, there is no code in my js files that sends it.
Solution:
YAHOO.util.Event.preventDefault(event);
at the beginning of the form submit event handler.
See also http://developer.yahoo.com/yui/examples/event/eventsimple.html