I'm trying to get an image from the link:
http://www.ims.gov.il/Ims/Map/MapRender.aspx?type=weather&LangId=1&Optional=c&Tab=Temperature
Sometimes it works, and at other times instead of getting an image I receive this strange HTML:
<html><body><script>document.cookie='rrrrrrr=27b8c912rrrrrrr_27b8c912; path=/';window.location.href=window.location.href;</script></body></html>
What does it mean and how can I bypass this to get the image?
I've encountered this problem in my Android app which uses URLConnection, and reproduced it in chrome with incognito mode and blocked javascript and cookies.
The response is setting a cookie and then attempting to reload the page. Some things you could try:
Just re-request the image if the first attempt fails.
Try setting the cookie yourself in the URL request.
Related
On a website, I frequently load an HTML containing an image viewer into an iframe by setting iframe/#source to the target address.
Usually, this works fine, e.g. http://dev2.hab.de/edoc/view.html?id=edoc_ed000216_f010_transcript displays the requested page (http://diglib.hab.de/show_image.php?dir=drucke/li-10249&distype=imgs&image=00033) just fine.
But right next door, if http://dev2.hab.de/edoc/view.html?id=edoc_ed000244_f02-widmungsvorrede tries to load the exact same page, I get an error in Chrome (67.0):
Cross-Origin Read Blocking (CORB) blocked cross-origin response
http://diglib.hab.de/show_image.php?dir=drucke/li-
10249&distype=imgs&image=00033 with MIME type text/html.
Firefox (60.0.2) also shows the page in the first but not the second case but does not even display any message in the console.
Any ideas whether I missed something obvious or any other hints are highly appreciated.
I am using cross domain data calls in my chrome extension. I have created a PHP function to make use of an API. So I'm making a call to this function using JSONP and expecting to get the values in return. But this is the error I'm getting in the console.
Can anyone help me with this. What is the problem here? What do I have to do? I do not have any experience with chrome extensions.
In my situation I think that only YouTube is blocking the content because it is expecting the cross domain connections to be HTTPS. So it's not allowing the cross domain calls. Well that's what I think. But if that problem can be solved using a background script. Can you please help with how to proceed?
I get the same problem like yours, and, I just change my AJAX URL to HTTPS, like this:
My old URL is
var url="http://fanyi.youdao.com/openapi.do?keyfrom=fgbnbb&key=1276642867&type=data&doctype=json&version=1.1&q="+txt;
And then, I change it to var url="https://fanyi.youdao.com/openapi.do?keyfrom=fgbnbb&key=1276642867&type=data&doctype=json&version=1.1&q="+txt;,
and then, the problem is gone.
Looked over some relevant posts:
Why am I getting a 404 error with ng-src even though image is appearing?
AngularJS ng-src path to image
Understanding AngularJS ng-src
Conditionally change img src based on model data
but none have the exact same symptoms.
This line of code,
<img ng-src="{{movie.Poster}}" alt="">
where movie is JSON and movie.Poster is a string of a url, seems to be the root of this error:
GET http://ia.media-imdb.com/images/M/MV5BMTk3OTIzODUyOV5BMl5BanBnXkFtZTYwNjgxNjA5._V1_SX300.jpg 403 (Forbidden)
Because the image url is good and complete in the error, the url string property movie.Poster seems to have been passed to ng-src ok/in time. However, many of the seemingly relevant posts emphasize that asynchronicity of JS may be responsible (and in this case movie.Poster does depend on a response from an API).
But if the url is in the error, why does ng-src have a problem requesting the image and displaying anything at all? An above post closest to my issue was able to load the image AND give the console error...
Perhaps the oddest thing is if I navigate to the image url (by copying and pasting that url) into another tab on the browser, then return to my app and click back then forward, the image loads without error!
I tried ng-if="movie.Poster"
and...
$scope anotherVar = movie.Poster in the controller and then ng-src="{{anotherVar}}"
Your Error is 403.
Which indicate that the server can be reached and understood the request, but refuses to take any further action. Status code 403 responses are the result of the web server being configured to deny access, for some reason, to the requested resource by the client .
Your image URL may be correct but you don’t have permission to access that.
http://ia.media-imdb.com/images/M/MV5BMTk3OTIzODUyOV5BMl5BanBnXkFtZTYwNjgxNjA5._V1_SX300.jpg
Doesn't seem to be an angular problem, as much as one with the API,
403 when trying to download a remote image
403 error for loading image from http and not https
Confused about how to handle CORS OPTIONS preflight requests
So, it seems that the headers need to be modified according to the first linked post in this answer...
But I checked that User-Agent is defined in the request to the image and it is...Even tried hard-coding one of the urls in the ng-src and THAT gave same 403...
AND I have colleagues who built the same app with same api without issue!
We had an interesting issue this morning - the details of the issue itself aren't relevant here, and I already fixed it, but I did run into something strange, to me, about jQuery.
The site I am building internally runs on https, only, so Apache is set to redirect any inbound http request to its https equivalent. This redirect is working fine. But, I had a bug in my software where I was trying to send the following ajax request:
jQuery.ajax({ type: "PUT",
url: "http://somewhere.com/cmdt/todo_lists/8457/toggle",
data: { deployment_id: 827},
dataType: "script"});
I understand that this would fail - I'm alright with jQuery not wanting to follow a redirect. But the actual behaviour is even weirder: I never see an xhr request go out at all! And there's no javascript error! It just fails, silently. If I change the url to https, or to a relative path, it works fine, no problem. My question is, why wasn't it TRYING to send out the request before? And why didn't it raise an error?
The reason you're not getting a failure is because it's a cross-site request, and so instead of using XMLHttpRequest, it's actually generating an HTML <script> tag and dropping it into the DOM, and using that mechanism to load the file.
This works reasonably well (considering it's a complete hack around wrong-headed browser "security" notions) but there's no way for jQuery to trap errors at that point, sadly. You will likely get a browser error if you have developer mode turned on, but that's it.
If you run that from an url that's https and try to open the equivalent http page you run into cross domain problems due to the different protocols they use. Have a look at same origin policy.
For posting AJAX forms in a form with many parameters, I am using a solution of creating an iframe, posting the form to it by POST, and then accessing the iframe's content.
specifically, I am accessing the content like this:
$("some_iframe_id").get(0).contentWindow.document
I tested it and it worked.
On some of the pages, I started getting an "Access is denied" error. As far as I know, this shouldn't happen if the iframe is served from the same domain.
I'm pretty sure it was working before. Anybody have a clue?
If I'm not being clear enough: I'm posting to the same domain. So this is not a cross-domain request. I am testing on IE only.
P.S. I can't use simple ajax POST queries (don't ask...)
Solved it by myself!
The problem was, that even though the correct response was being sent (verified with Fiddler), it was being sent with an HTTP 500 error code (instead of 200).
So it turns out, that if a response is sent with an error code, IE replaces the content of the iframe with an error message loaded from the disk (res://ieframe.dll/http_500.htm), and that causes the cross-domain access denied error.
Beware of security limitations associated to iFrames, like Cross domain restriction (aka CORS). Below are 3 common errors related to CORS :
Load an iFrame with a different domain. (Ex: opening "www.foo.com" while top frame is "www.ooof.com")
Load an iFrame with a different port: iFrame's URL port differs from the one of the top frame.
Different protocols : loading iFrame resource via HTTPS while parent Frame uses HTTP.
My issue was the X-Frame-Options HTTP header. My Apache configuration has it set to:
Header always append X-Frame-Options DENY
Removing it allowed it to work. Specifically in my case I was using iframe transport for jQuery with the jQuery file upload plugin to upload files in IE 9 and IE 10.
I know this question is super-old, but I wanted to mention that the above answer worked for me: setting the document.domain to be the same on each of the pages-- the parent page and the iframe page. However in my search, I did find this interesting article:
http://softwareas.com/cross-domain-communication-with-iframes
Note if you have a iframe with src='javascript:void(0)' then javascript like frame.document.location =... will fail with Access Denied error in IE. Was using a javascript library that interacts with a target frame. Even though the location it was trying to change the frame to was on the same domain as parent, the iframe was initially set to javascript:void which triggered the cross domain access denied error.
To solve this I created a blank.html page in my site and if I need to declare an iframe in advance that will initially be blank until changed via javascript, then I point it to the blank page so that src='/content/blank.html' is in the same domain.
Alternatively you could create the iframe completely through javascript so that you can set the src when it is created, but in my case I was using a library which reqired an iframe already be declared on the page.
Basically, this error occurs when the document in frame and outside of ii have different domains. So to prevent cross-side scripting browsers disable such execution.
if it is a domain issue (or subdomain) such as www.foo.com sending a request to www.api.foo.com
on each page you can set the
document.domain = www.foo.com
to allow for "cross-domain" permissions