New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chrome: Resource interpreted as Image but transferred with MIME type text/javascript. #32

Closed
forresto opened this Issue Apr 6, 2011 · 37 comments

Comments

Projects
None yet
@forresto

forresto commented Apr 6, 2011

For every script that I'm loading with yepnope, I'm getting this warning in the console:

jquery.min.js:-1 Resource interpreted as Image but transferred with MIME type text/javascript.

I'm not getting these warnings in Firefox or Safari.

Thanks for the nice tool :)

@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Apr 6, 2011

Collaborator

Heyo,

This is intended because we use images to preload resources certain versions of webkit in yepnope. There's nothing we can do about the warnings. They're not breaking your page. I would suggest clicking the "Errors" or "Logs" button on the console tab of the web inspector to find the messages you're looking for.

Thanks,

Ralph

Collaborator

ralphholzmann commented Apr 6, 2011

Heyo,

This is intended because we use images to preload resources certain versions of webkit in yepnope. There's nothing we can do about the warnings. They're not breaking your page. I would suggest clicking the "Errors" or "Logs" button on the console tab of the web inspector to find the messages you're looking for.

Thanks,

Ralph

@forresto

This comment has been minimized.

Show comment
Hide comment
@forresto

forresto Apr 6, 2011

I see. I also noticed that yepnope'ing the jquery ui css can hold things up for 10 seconds or so. Is it waiting for all of the images as well?

yepnope('http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.11/themes/eggplant/jquery-ui.css');

forresto commented Apr 6, 2011

I see. I also noticed that yepnope'ing the jquery ui css can hold things up for 10 seconds or so. Is it waiting for all of the images as well?

yepnope('http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.11/themes/eggplant/jquery-ui.css');
@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Apr 12, 2011

Collaborator

I would double check to make sure all of your resources exist. Check out the "Errors and Timeouts" section of yepnopejs.com. We use a timeout mechanism in yepnope that continues execution after a set amount of time if an onload handler fails or times out. The default is 10 seconds. So if your page is stalling for 10 seconds, this likely means that something is returning a 404 or taking a very long time to load.

Collaborator

ralphholzmann commented Apr 12, 2011

I would double check to make sure all of your resources exist. Check out the "Errors and Timeouts" section of yepnopejs.com. We use a timeout mechanism in yepnope that continues execution after a set amount of time if an onload handler fails or times out. The default is 10 seconds. So if your page is stalling for 10 seconds, this likely means that something is returning a 404 or taking a very long time to load.

@unjust

This comment has been minimized.

Show comment
Hide comment
@unjust

unjust Jun 6, 2011

The only drawback I see to Chrome's warnings is that I am unable to set breakpoints in my js code to debug :\

unjust commented Jun 6, 2011

The only drawback I see to Chrome's warnings is that I am unable to set breakpoints in my js code to debug :\

@anselmh

This comment has been minimized.

Show comment
Hide comment
@anselmh

anselmh Jul 13, 2011

My console says: "uncaught ReferenceError: $ is not defined" when calling a jQuery action. I use this code:

yepnope([{
    load: '//code.jquery.com/jquery-1.6.1.min.js',
    complete: function () {
        if (!window.jQuery) {
            yepnope('[[++base_url]]assets/templates/main/js/libs/jquery-1.6.1.min.js');
        }
    }
}, {
    load: ['[[++base_url]]assets/templates/main/js/plugins.js', '[[++base_url]]assets/templates/main/js/scripts.js'  ]
}]);

If I simulate CDN is down (no internet connection or wrong URL) I get these errors. jQuery is loaded, I get the error message that it's interpreted as image but is js…
Used Chrome + Firefox.

Any suggestions?

anselmh commented Jul 13, 2011

My console says: "uncaught ReferenceError: $ is not defined" when calling a jQuery action. I use this code:

yepnope([{
    load: '//code.jquery.com/jquery-1.6.1.min.js',
    complete: function () {
        if (!window.jQuery) {
            yepnope('[[++base_url]]assets/templates/main/js/libs/jquery-1.6.1.min.js');
        }
    }
}, {
    load: ['[[++base_url]]assets/templates/main/js/plugins.js', '[[++base_url]]assets/templates/main/js/scripts.js'  ]
}]);

If I simulate CDN is down (no internet connection or wrong URL) I get these errors. jQuery is loaded, I get the error message that it's interpreted as image but is js…
Used Chrome + Firefox.

Any suggestions?

@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Aug 25, 2011

@smooth-graphics instead of using complete, try callback. This way when jquery is trying to be loaded it tests to see if it even exists. When it does not, you then try to load the fallback alternative. You may also want to play around with errorTimeout as I believe the default timeout is too long (10 seconds?) before it loads the fallback.

Sample snippet

scripts = {
    'jQuery': '//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'
    ,'jQuery_fallback': '/js/lib/jquery-1.6.2.min.js'
}

yepnope([{
...
callback: function (url, result, key) {
            if (url === scripts.jQuery) {
                if (!window.jQuery) {
                    Modernizr.load(scripts.jQuery_fallback);
                    console.log("Detected Google API errors, loading jQuery from our servers instead.");
                }
            }
        }
....

JasonGiedymin commented Aug 25, 2011

@smooth-graphics instead of using complete, try callback. This way when jquery is trying to be loaded it tests to see if it even exists. When it does not, you then try to load the fallback alternative. You may also want to play around with errorTimeout as I believe the default timeout is too long (10 seconds?) before it loads the fallback.

Sample snippet

scripts = {
    'jQuery': '//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'
    ,'jQuery_fallback': '/js/lib/jquery-1.6.2.min.js'
}

yepnope([{
...
callback: function (url, result, key) {
            if (url === scripts.jQuery) {
                if (!window.jQuery) {
                    Modernizr.load(scripts.jQuery_fallback);
                    console.log("Detected Google API errors, loading jQuery from our servers instead.");
                }
            }
        }
....
@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Aug 25, 2011

"This is intended because we images to preload resources certain versions of webkit in yepnope.".

Why only certain versions? And why?

JasonGiedymin commented Aug 25, 2011

"This is intended because we images to preload resources certain versions of webkit in yepnope.".

Why only certain versions? And why?

@vdh

This comment has been minimized.

Show comment
Hide comment
@vdh

vdh Dec 16, 2011

It would have been nice if these intentional errors had been mentioned in yepnope's documentation somewhere, before I tried to debug them thinking I had made a mistake.

vdh commented Dec 16, 2011

It would have been nice if these intentional errors had been mentioned in yepnope's documentation somewhere, before I tried to debug them thinking I had made a mistake.

@albell

This comment has been minimized.

Show comment
Hide comment
@albell

albell Aug 20, 2012

+1 for adding this explanation to the docs. It's confusing to encounter as a newb. Tell the people up front, please!

@JasonGiedymin What is different about callback versus complete exactly? The if (!window.jQuery) call is the same either way. The docs make no clear distinction. Can you possibly explain?

albell commented Aug 20, 2012

+1 for adding this explanation to the docs. It's confusing to encounter as a newb. Tell the people up front, please!

@JasonGiedymin What is different about callback versus complete exactly? The if (!window.jQuery) call is the same either way. The docs make no clear distinction. Can you possibly explain?

@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Aug 20, 2012

It has been a while since I've used yepnope but lets see what I can muster. Callback is run after each script is 'loaded' or 'acted' upon. The complete event happens only after when all scripts have loaded. If your trying to load scripts that rely on jQuery you want to load your fallback right away so that you can continue and load your scripts. Waiting until the end won't be helpful.

JasonGiedymin commented Aug 20, 2012

It has been a while since I've used yepnope but lets see what I can muster. Callback is run after each script is 'loaded' or 'acted' upon. The complete event happens only after when all scripts have loaded. If your trying to load scripts that rely on jQuery you want to load your fallback right away so that you can continue and load your scripts. Waiting until the end won't be helpful.

@albell

This comment has been minimized.

Show comment
Hide comment
@albell

albell Aug 20, 2012

Well, it seems like the whole point of this is to decouple "loading" and "acting upon (aka execution)" . Those two things are not the same, right? If you're not doing any feature tests, just loading in sequence, it's my understanding that both callback and complete script sets happen after both the loading and the execution of any scripts nested in a load object in the same block. A script listed in a complete object doesn't wait until the execution of every single script on the entire page. If there are both callback and complete script sets, then the complete will run after the callback. But if you're using just one of the two, I really don't see the difference.

albell commented Aug 20, 2012

Well, it seems like the whole point of this is to decouple "loading" and "acting upon (aka execution)" . Those two things are not the same, right? If you're not doing any feature tests, just loading in sequence, it's my understanding that both callback and complete script sets happen after both the loading and the execution of any scripts nested in a load object in the same block. A script listed in a complete object doesn't wait until the execution of every single script on the entire page. If there are both callback and complete script sets, then the complete will run after the callback. But if you're using just one of the two, I really don't see the difference.

@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Aug 21, 2012

The issue here is that when in chrome it uses the image loader and will show up as such. It behaves differently.

Please post a new issue if you feel there us a bug.

-Jason

On Aug 20, 2012, at 7:57 PM, baloneysandwiches notifications@github.com wrote:

Well, it seems like the whole point of this is to decouple "loading" and "acting upon," aka execution. Those two things are not the same, right? If you're not doing any feature tests, just loading in sequence, it's my understanding that both callback and complete script sets happen after both the loading and the execution of any scripts nested in a load object in the same block. A script listed in a complete object doesn't wait until the execution of every single script on the entire page. If there are both callback and complete script sets, then the complete will run after the callback. But if you're using just one of the two, I really don't see the difference.


Reply to this email directly or view it on GitHub.

JasonGiedymin commented Aug 21, 2012

The issue here is that when in chrome it uses the image loader and will show up as such. It behaves differently.

Please post a new issue if you feel there us a bug.

-Jason

On Aug 20, 2012, at 7:57 PM, baloneysandwiches notifications@github.com wrote:

Well, it seems like the whole point of this is to decouple "loading" and "acting upon," aka execution. Those two things are not the same, right? If you're not doing any feature tests, just loading in sequence, it's my understanding that both callback and complete script sets happen after both the loading and the execution of any scripts nested in a load object in the same block. A script listed in a complete object doesn't wait until the execution of every single script on the entire page. If there are both callback and complete script sets, then the complete will run after the callback. But if you're using just one of the two, I really don't see the difference.


Reply to this email directly or view it on GitHub.

@montlebalm

This comment has been minimized.

Show comment
Hide comment
@montlebalm

montlebalm Dec 19, 2012

So the solution to the warnings is to turn warnings off? Sounds legit.

montlebalm commented Dec 19, 2012

So the solution to the warnings is to turn warnings off? Sounds legit.

@SlexAxton

This comment has been minimized.

Show comment
Hide comment
@SlexAxton

SlexAxton Dec 19, 2012

Owner

Here are the warnings on your personal website:

http://f.cl.ly/items/1m431V0F3s0C381G1z2R/Screen%20Shot%202012-12-19%20at%203.09.17%20PM.png

Has anyone complained about them yet?

Owner

SlexAxton commented Dec 19, 2012

Here are the warnings on your personal website:

http://f.cl.ly/items/1m431V0F3s0C381G1z2R/Screen%20Shot%202012-12-19%20at%203.09.17%20PM.png

Has anyone complained about them yet?

@albell

This comment has been minimized.

Show comment
Hide comment
@albell

albell Dec 19, 2012

:) ok, ok! Just out of curiousity--Alex can you actually explain what Ralph meant when he said "This is intended because we images to preload resources certain versions of webkit in yepnope." I'm not nitpicking about the grammar--I'm actually trying to understand how yepnope works. "Images" of what?

albell commented Dec 19, 2012

:) ok, ok! Just out of curiousity--Alex can you actually explain what Ralph meant when he said "This is intended because we images to preload resources certain versions of webkit in yepnope." I'm not nitpicking about the grammar--I'm actually trying to understand how yepnope works. "Images" of what?

@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Dec 19, 2012

Collaborator

It was a typo -- we use images to preload resources in yepnope.

Collaborator

ralphholzmann commented Dec 19, 2012

It was a typo -- we use images to preload resources in yepnope.

@albell

This comment has been minimized.

Show comment
Hide comment
@albell

albell Dec 19, 2012

Yeah I figured that out. I'm actually just curious about the how and why?

albell commented Dec 19, 2012

Yeah I figured that out. I'm actually just curious about the how and why?

@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Dec 19, 2012

Kinda like a hack

-Jason

On Dec 19, 2012, at 6:25 PM, baloneysandwiches notifications@github.com wrote:

Yeah I figured that out. I'm actually just curious about the how and why?


Reply to this email directly or view it on GitHub.

JasonGiedymin commented Dec 19, 2012

Kinda like a hack

-Jason

On Dec 19, 2012, at 6:25 PM, baloneysandwiches notifications@github.com wrote:

Yeah I figured that out. I'm actually just curious about the how and why?


Reply to this email directly or view it on GitHub.

@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Dec 19, 2012

Collaborator

Totally.

On Dec 19, 2012, at 5:45 PM, Jason Giedymin notifications@github.com wrote:

Kinda like a hack

-Jason

On Dec 19, 2012, at 6:25 PM, baloneysandwiches notifications@github.com wrote:

Yeah I figured that out. I'm actually just curious about the how and why?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

Collaborator

ralphholzmann commented Dec 19, 2012

Totally.

On Dec 19, 2012, at 5:45 PM, Jason Giedymin notifications@github.com wrote:

Kinda like a hack

-Jason

On Dec 19, 2012, at 6:25 PM, baloneysandwiches notifications@github.com wrote:

Yeah I figured that out. I'm actually just curious about the how and why?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub.

@montlebalm

This comment has been minimized.

Show comment
Hide comment
@montlebalm

montlebalm Dec 20, 2012

@SlexAxton So someone comments about a hacky workaround and you reply with an ad hominem attack? You sound like a real stand up guy.

I don't expect users to notice warnings on websites they visit. I do expect developers to be annoyed by constant pollution of the console. Turning off warnings is not a savvy solution for developers (i.e., people consuming your code).

montlebalm commented Dec 20, 2012

@SlexAxton So someone comments about a hacky workaround and you reply with an ad hominem attack? You sound like a real stand up guy.

I don't expect users to notice warnings on websites they visit. I do expect developers to be annoyed by constant pollution of the console. Turning off warnings is not a savvy solution for developers (i.e., people consuming your code).

@JasonGiedymin

This comment has been minimized.

Show comment
Hide comment
@JasonGiedymin

JasonGiedymin Dec 20, 2012

Guys lets relax. If you truly believe something should be changed you have the right to fork. And if there is enough community support around any particular issue I would hope that the src owner accept some dialogue, but these things take time. Either way there is a solution for everyone. And lets not forget to not bit the hand that feeds us eh?

JasonGiedymin commented Dec 20, 2012

Guys lets relax. If you truly believe something should be changed you have the right to fork. And if there is enough community support around any particular issue I would hope that the src owner accept some dialogue, but these things take time. Either way there is a solution for everyone. And lets not forget to not bit the hand that feeds us eh?

@SlexAxton

This comment has been minimized.

Show comment
Hide comment
@SlexAxton

SlexAxton Dec 20, 2012

Owner

@montlebalm I did not reply with an 'ad hominem' attack. The fact that you have warnings on your site is a perfectly valid argument that warnings are an accepted part of developing websites. In fact I was stating that your website is in a good/acceptable state. It would be 'ad hominem' if I was saying that your site was bad because of the warnings. The point of warnings are to point developers in the direction of something that might go wrong, but they aren't errors.

The preloading of scripts in yepnope uses images as the mechanism. It's a hack to get things to work in every browser. Using the cache that is primed with images, yepnope can be certain that the next injection of the script will happen immediately, rather than after a network delay. You could not 'fork' yepnope and keep this behavior without doing preloading. There are other ways to do async loading in-order script execution, but they break features in yepnope. It's the exact same reason that you have a box-sizing warning in your CSS. Because we often add all possibilities to our CSS in order to cover all bases and make things compatible everywhere.

The warning for most people serves as a way of telling that they may not be sending the right headers for their images. However, we are well aware of the headers that we are sending for scripts are the incorrect ones for images. So you can safely ignore the warning.

If you are being 'annoyed by constant pollution of the console', then you should seriously reconsider how many scripts you are loading with yepnope. 3 or less is a best practice, and the consequences of loading more are far far more serious than a developer needing to adjust their eyes 10 to 20 pixels during a console debugging scenario.

Owner

SlexAxton commented Dec 20, 2012

@montlebalm I did not reply with an 'ad hominem' attack. The fact that you have warnings on your site is a perfectly valid argument that warnings are an accepted part of developing websites. In fact I was stating that your website is in a good/acceptable state. It would be 'ad hominem' if I was saying that your site was bad because of the warnings. The point of warnings are to point developers in the direction of something that might go wrong, but they aren't errors.

The preloading of scripts in yepnope uses images as the mechanism. It's a hack to get things to work in every browser. Using the cache that is primed with images, yepnope can be certain that the next injection of the script will happen immediately, rather than after a network delay. You could not 'fork' yepnope and keep this behavior without doing preloading. There are other ways to do async loading in-order script execution, but they break features in yepnope. It's the exact same reason that you have a box-sizing warning in your CSS. Because we often add all possibilities to our CSS in order to cover all bases and make things compatible everywhere.

The warning for most people serves as a way of telling that they may not be sending the right headers for their images. However, we are well aware of the headers that we are sending for scripts are the incorrect ones for images. So you can safely ignore the warning.

If you are being 'annoyed by constant pollution of the console', then you should seriously reconsider how many scripts you are loading with yepnope. 3 or less is a best practice, and the consequences of loading more are far far more serious than a developer needing to adjust their eyes 10 to 20 pixels during a console debugging scenario.

@SlexAxton

This comment has been minimized.

Show comment
Hide comment
@SlexAxton

SlexAxton Dec 20, 2012

Owner

Furthermore, your original comment was much closer to an ad hominem attack, and was kind of a dick move.

Owner

SlexAxton commented Dec 20, 2012

Furthermore, your original comment was much closer to an ad hominem attack, and was kind of a dick move.

@montlebalm

This comment has been minimized.

Show comment
Hide comment
@montlebalm

montlebalm Dec 20, 2012

@JasonGiedymin Agreed.

@SlexAxton Yepnope is great. If the warnings are a necessary part of the implementation they should stay. However, I think they should be removed if at all possible for developer's sake.

montlebalm commented Dec 20, 2012

@JasonGiedymin Agreed.

@SlexAxton Yepnope is great. If the warnings are a necessary part of the implementation they should stay. However, I think they should be removed if at all possible for developer's sake.

@hocine

This comment has been minimized.

Show comment
Hide comment
@hocine

hocine Dec 24, 2012

What the heck, is there any solution for this? It's irksome.

Screenshot from 2012-12-24 17:57:44

hocine commented Dec 24, 2012

What the heck, is there any solution for this? It's irksome.

Screenshot from 2012-12-24 17:57:44

@SlexAxton

This comment has been minimized.

Show comment
Hide comment
@SlexAxton

SlexAxton Dec 25, 2012

Owner

As noted above, we're doing this intentionally and these warnings can be
safely ignored.

Owner

SlexAxton commented Dec 25, 2012

As noted above, we're doing this intentionally and these warnings can be
safely ignored.

@nattarnoff

This comment has been minimized.

Show comment
Hide comment
@nattarnoff

nattarnoff Feb 2, 2013

I know this issue is closed and old, but while I understand they can be ignored, I can't get my QA and Stakeholders to sign off on projects with JS errors showing up. An explanation of why they are used so I can look to see if I need to fork it would have been nice.

nattarnoff commented Feb 2, 2013

I know this issue is closed and old, but while I understand they can be ignored, I can't get my QA and Stakeholders to sign off on projects with JS errors showing up. An explanation of why they are used so I can look to see if I need to fork it would have been nice.

@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Feb 2, 2013

Collaborator

Tell them they're not errors, because they're not, they're warnings.

On Feb 2, 2013, at 10:33 AM, Greg Tarnoff notifications@github.com wrote:

I know this issue is closed and old, but while I understand they can be ignored, I can't get my QA and Stakeholders to sign off on projects with JS errors showing up. An explanation of why they are used so I can look to see if I need to fork it would have been nice.


Reply to this email directly or view it on GitHub.

Collaborator

ralphholzmann commented Feb 2, 2013

Tell them they're not errors, because they're not, they're warnings.

On Feb 2, 2013, at 10:33 AM, Greg Tarnoff notifications@github.com wrote:

I know this issue is closed and old, but while I understand they can be ignored, I can't get my QA and Stakeholders to sign off on projects with JS errors showing up. An explanation of why they are used so I can look to see if I need to fork it would have been nice.


Reply to this email directly or view it on GitHub.

@nattarnoff

This comment has been minimized.

Show comment
Hide comment
@nattarnoff

nattarnoff Feb 2, 2013

My bad in saying errors. Company policy is no shipping with errors,
warnings, issues in any public facing product. I have also communicated
what documentation is available on the topic, with no avail.

On Sat, Feb 2, 2013 at 10:39 AM, Ralph Holzmann notifications@github.comwrote:

Tell them they're not errors, because they're not, they're warnings.

On Feb 2, 2013, at 10:33 AM, Greg Tarnoff notifications@github.com
wrote:

I know this issue is closed and old, but while I understand they can be
ignored, I can't get my QA and Stakeholders to sign off on projects with JS
errors showing up. An explanation of why they are used so I can look to see
if I need to fork it would have been nice.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-13033168.

nattarnoff commented Feb 2, 2013

My bad in saying errors. Company policy is no shipping with errors,
warnings, issues in any public facing product. I have also communicated
what documentation is available on the topic, with no avail.

On Sat, Feb 2, 2013 at 10:39 AM, Ralph Holzmann notifications@github.comwrote:

Tell them they're not errors, because they're not, they're warnings.

On Feb 2, 2013, at 10:33 AM, Greg Tarnoff notifications@github.com
wrote:

I know this issue is closed and old, but while I understand they can be
ignored, I can't get my QA and Stakeholders to sign off on projects with JS
errors showing up. An explanation of why they are used so I can look to see
if I need to fork it would have been nice.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-13033168.

@ralphholzmann

This comment has been minimized.

Show comment
Hide comment
@ralphholzmann

ralphholzmann Feb 2, 2013

Collaborator

Unfortunately, there's not much that can be done until 2.0 (which is only in the planning stages). You can try and hack around it starting on line 34 by replacing img with script, but other than that, not sure what to tell you.

Collaborator

ralphholzmann commented Feb 2, 2013

Unfortunately, there's not much that can be done until 2.0 (which is only in the planning stages). You can try and hack around it starting on line 34 by replacing img with script, but other than that, not sure what to tell you.

@vdavid

This comment has been minimized.

Show comment
Hide comment
@vdavid

vdavid Feb 3, 2013

If it's a really high priority to get rid off the warnings, an ugly workaround is to load all yepnope-loaded JS files from the localhost, put them in a separate dir and put there a .htaccess with something like

AddType image/jpeg .js # To avoid YepNope warnings

Not beautiful, but surely works (tested on Apache).

vdavid commented Feb 3, 2013

If it's a really high priority to get rid off the warnings, an ugly workaround is to load all yepnope-loaded JS files from the localhost, put them in a separate dir and put there a .htaccess with something like

AddType image/jpeg .js # To avoid YepNope warnings

Not beautiful, but surely works (tested on Apache).

@Francolpm

This comment has been minimized.

Show comment
Hide comment
@Francolpm

Francolpm May 3, 2013

THE PROBLEM IS THIS! ----> check your css code because in some place you have for sure some like this:

.someting {
background: #fff url();
}
REMOVE the url() from background or put some image for it.

Regards

Francolpm commented May 3, 2013

THE PROBLEM IS THIS! ----> check your css code because in some place you have for sure some like this:

.someting {
background: #fff url();
}
REMOVE the url() from background or put some image for it.

Regards

@OscarGodson

This comment has been minimized.

Show comment
Hide comment
@OscarGodson

OscarGodson Aug 12, 2013

@ralphholzmann So, this is breaking pages now that implement CSP. Since it's transferred as a type of image IE11 will run the default-src content policy against it thus making the script not load at all unless you then make all your default-src's the same as your script-src's.

OscarGodson commented Aug 12, 2013

@ralphholzmann So, this is breaking pages now that implement CSP. Since it's transferred as a type of image IE11 will run the default-src content policy against it thus making the script not load at all unless you then make all your default-src's the same as your script-src's.

@naoyeye

This comment has been minimized.

Show comment
Hide comment
@naoyeye

naoyeye commented Sep 3, 2013

Thanks @Francolpm !!

@malei0311

This comment has been minimized.

Show comment
Hide comment
@malei0311

malei0311 Nov 22, 2013

@naoyeye you have solve the problem?

malei0311 commented Nov 22, 2013

@naoyeye you have solve the problem?

@jrevillini

This comment has been minimized.

Show comment
Hide comment
@jrevillini

jrevillini Mar 9, 2014

You might also have something silly in css like

something{background:url(http://yoursite.com/)}

To find it, you can see in the warning the URL of the item that is being transferred with the wrong mime type and use that to search CSS. If the affected site is a Wordpress site, it might make sense to use Autoptimizer to minify everything and then be able to search all the CSS in one shot, then figure out where that code comes from by looking at the classes in the selectors.

Thank you so much @Francolpm !

jrevillini commented Mar 9, 2014

You might also have something silly in css like

something{background:url(http://yoursite.com/)}

To find it, you can see in the warning the URL of the item that is being transferred with the wrong mime type and use that to search CSS. If the affected site is a Wordpress site, it might make sense to use Autoptimizer to minify everything and then be able to search all the CSS in one shot, then figure out where that code comes from by looking at the classes in the selectors.

Thank you so much @Francolpm !

@rtud

This comment has been minimized.

Show comment
Hide comment
@rtud

rtud May 22, 2014

@jrevillini that was just the case for me, thanks! 👍

rtud commented May 22, 2014

@jrevillini that was just the case for me, thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment