Originally Posted by
Daniil
Hi @michaeld,
1. SSL CDN
Yes, currently, CDN doesn't support SSL to request the resources with "https".
Presently I have to do the following:
rm.RenderScripts = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;
rm.RenderStyles = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;
It just makes sense to me that this logic should be moved inside of the ResourceManager rendering. A check for IsSecureConnection, and if so, override back to default. Anyway, it's just a thought since this can cause an issue for clients who have secure pages since your cdn doesn't support secure. It's actually kind of frustrating this is the case because https already causes otherwise cached pages to be slow because the different port causes a full load (thus slowing this page more than the rest of the website).
Originally Posted by
Daniil
So, you need to turn CDN off to avoid a security warning because of requesting the resources with insecure "http", is that correct?
Effectively, yes. It's a shame this is the case since there is nothing insecure about the contents.
Originally Posted by
Daniil
2. Getting ExtJS resources from CDN, but not Ext.NET
Generally, it is not correct to organize the things such a way. Ext.NET scripts tightly depends on ExtJS scripts. They must be the same version.
If we keep this feature request very basic, this comes down to breaking out /extjs which includes 2 files [js & css] from /extnet/ which includes 2-3 files depending on resource manager config. The extjs js file is the largest component of the entire application.
We understand that extjs resources version separately from extnet, and extnet is always based on a specific version of extjs. So nothing about your statement changes. You're still tightly bound to an extjs version because the trunk code is bound to a specific version of extjs on the cdn until you decide to upload something new on the cdn or reversion the trunk.
The most important aspect about this cdn feature request is it makes your clients able to offload downloading the largest file from your application from the cdn if they need a latest fix only available from the trunk. I may actually be inclined enough to code this myself since my site has limited bandwidth and resources at launch.
Originally Posted by
Daniil
3. GZip
Thank you for the report. Seems the main ExtJS script comes not gzipped from CDN. All the rest resources seems to be gzipped. We are investigating.
To me this is kind of a big deal because extjs-all is huge. It makes no sense to use the CDN if theoretically you can bounce a smaller file to your client's browser as fast at the same speed as the CDN can at full-size. ;)
Originally Posted by
Daniil
Cool
Originally Posted by
Daniil
5. CDNPath
A nice suggestion. Added to SVN trunk. Thank you again.
If you consider my feature request in 2, this would still work..