Css loaded more than once when using custom combo loader

[F21]

Here's a simple repo ( http://jsfiddle.net/tPFTX/ ):

YUI.applyConfig({

    "combine": true,
//    "comboBase": "/combo?", //Use Yahoo's CDN
    "modules": {
        "some-module": {
            "requires": ["node"],
            "path": "some-module/some-module.js"
        },
    }
});

YUI().use('selector-css3', 'node', 'json', 'anim', 'transition', 'widget', 'button', function (Y) {
    YUI.add('button2', function(Y) {

    }, '1.0.0', { requires: ['node','base','widget','selector-css3', 'button']});

     YUI.add('button3', function(Y) {

    }, '1.0.0', { requires: ['node','base','widget','selector-css3', 'button']});

    YUI.add('button4', function(Y) {

    }, '1.0.0', { requires: ['node','base','widget','selector-css3', 'button']});

    Y.use('button2', 'button3');
    Y.use('button4');

});

If I run this, notice that the css for widget-base and cssbutton is downloaded once.

However, if I now set my own comboBase: http://jsfiddle.net/JYdPB/

We see that the css for widget-base and cssbutton is downloaded multiple times:

[okuryu]

Perhaps you need to re-create YUI instance by call YUI() after called YUI.add().

[F21]

Can you explain more how that could be done? It is odd that this only occurs if I set a comboBase though. Using Yahoo's CDN does not cause this problem.

[okuryu]

hm.. When set "comboBase": "https://yui.yahooapis.com/combo?", it's seems to works. Have you ever tried combo endpoint to work?

[davglass]

It's loading it more than once on the fiddle because it encountered an error. It's not a 200 response, so it attempts again to get it.

[F21]

@davglass Hmm. When running on my local server using my own comboLoader, even though it receives the correct response (200), it still downloads the CSS 3 times.

When I inspect the requests in Firebug, I can confirm that indeed, the response is sent correctly and a status code of 200 was used.

[F21]

After more investigation, I think I have found the source of the problem.

The loader needs the correct content-type. In the case of CSS, it should be text\css. For whatever reason, my loader was setting the content-type to application\javascript for everything. I think it would be nice if this caveat is noted in the docs and guides.

[davglass]

This is not a caveat, this is just good practice. It's also not
Loaders fault, the browser is failing because the content type is
wrong.

[F21]

Perhaps caveat wasn't the right word for this, but I would still like to see this noted in the docs for loader (to explain that multiple requests to the same css files is not a bug if the content-type is incorrect). This can potentially save quite a lot of time (I actually spent a fair bit of today trying to find out why this is happening) for people using custom combo loaders.

[davglass]

I'll gladly accept a pull request for the docs, but I feel it's more
"common sense" than an issue to actually call out. A server should
return a proper content type, if not the servers a problem.