combres Issue Tracker Rss Feed

Commented Issue: current protocol should be used to construct CacheKeys [7659]

dplaskon — Wed, 08 May 2013 00:33:19 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Buu, I could be mistaken - but I think there is an issue with cache-vary providers in nested groups (at least there was the last time I played around with making one) - are you aware of such an issue?

Commented Issue: current protocol should be used to construct CacheKeys [7659]

buunguyen — Tue, 07 May 2013 18:08:07 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Modifying cache key the way you suggested is certainly one way to make this works. The reason I suggested building a custom cache-vary provider is because this approach increases the mem footprint and 1st-time performance hits for users who don't have to need to differentiate between HTTP and HTTPS requests (i.e. they don't use filters which modify content differently based on secure-connection status).

Commented Issue: current protocol should be used to construct CacheKeys [7659]

dplaskon — Tue, 07 May 2013 17:33:22 GMT

In RequestProcessor, the cache key is constructed as such:

CacheKey = string.Join("/",
new[]
{
CachePrefix,
typeof (RequestProcessor).ToString(),
setName,
version,
Compressor.EncodingName
}.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());

I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)
Comments: Buu, I think a more idiomatic solution would be to make the proposed change to the way the cache key is constructed in RequestProcessor (see my comment from Nov 17, 2011 at 1:30 PM). Is there some reason you believe this wouldn't be a good solution to the underlying issue here?

Commented Issue: Add an extension point for url creation [7678]

dplaskon — Tue, 07 May 2013 17:24:22 GMT

There are many great extension points in combres and I'd like to suggest that url creation be an area where this is considered. I recently moved to a new cdn provider that required file extensions to be added to the combres-generated js and css files to ensure that content types were required, which is what prompted me to create this ticket.

This could potentially eliminate the need for having the host and sslHost settings as well, as you could easily append any host name needed with the context of such an extension point.

I'm sure there are quite a few other uses that aren't coming to mind immediately.

Keep up the great work Buu!
Comments: No, I mean something akin to a transformer extension point for urls. For example, you get as input: 1) The name of the set to be created 2) The type of set to be created (eg. js vs css) 3) The hash for the set to be created 4) Access to the httpcontext and/or other interesting contextual information. And, as output, you provide the final url that combres will use for a given resource set.

Created Unassigned: Compile CSS with @import statments [7680]

adardesign — Mon, 29 Apr 2013 03:49:12 GMT

While compiling CSS resources, also inline the @import resources and then compile/build

Commented Issue: Add an extension point for url creation [7678]

adardesign — Mon, 29 Apr 2013 03:48:28 GMT

There are many great extension points in combres and I'd like to suggest that url creation be an area where this is considered. I recently moved to a new cdn provider that required file extensions to be added to the combres-generated js and css files to ensure that content types were required, which is what prompted me to create this ticket.

This could potentially eliminate the need for having the host and sslHost settings as well, as you could easily append any host name needed with the context of such an extension point.

I'm sure there are quite a few other uses that aren't coming to mind immediately.

Keep up the great work Buu!
Comments: Do you mean something like this? path/to/combresResource?resources=resourceID1,resourceID2,resourceID3 which would generate (minify uglify etc.) all required resources?

Created Unassigned: Compile process to include require statments resource [7679]

adardesign — Mon, 29 Apr 2013 03:44:47 GMT

I am looking to combine require.js functionality with combres.
The idea is that while building the script it will follow the require statements.. and addition/instead of the combres xml rules, it should generate the resource via the require (CommonJS) statements.

Closed Issue: jquery not loaded in ie 7 [7677]

buunguyen — Mon, 10 Sep 2012 04:49:47 GMT

there is a problem with jquery when I test in IE 7. Jquery don't loaded, so all function js not run.

Could you help me to resolve this issue.
Comments: Fixed by user

Commented Issue: jquery not loaded in ie 7 [7677]

thanhphung — Mon, 10 Sep 2012 03:38:20 GMT

there is a problem with jquery when I test in IE 7. Jquery don't loaded, so all function js not run.

Could you help me to resolve this issue.
Comments: Thanks Buunguyen, I think so, it resolved.

Created Issue: Add an extension point for url creation [7678]

dplaskon — Fri, 07 Sep 2012 21:23:40 GMT

Commented Issue: jquery not loaded in ie 7 [7677]

buunguyen — Wed, 05 Sep 2012 05:20:16 GMT

there is a problem with jquery when I test in IE 7. Jquery don't loaded, so all function js not run.

Could you help me to resolve this issue.
Comments: Please send a working project that has this issue.

Created Issue: jquery not loaded in ie 7 [7677]

thanhphung — Wed, 05 Sep 2012 04:45:29 GMT

there is a problem with jquery when I test in IE 7. Jquery don't loaded, so all function js not run.

Could you help me to resolve this issue.

Closed Issue: Wrong EncodingName in NullCompressor [7670]

buunguyen — Fri, 31 Aug 2012 17:02:23 GMT

Commented Issue: Wrong EncodingName in NullCompressor [7670]

buunguyen — Fri, 31 Aug 2012 16:48:11 GMT

Hi,

I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Comments: I see what you mean now. Yes, the "latest" points to "stable", not really "latest". Also, all the download binaries in CodePlex is obsolete; guess I should remove all of them. So either use NuGet or build from the real latest (359a404e315c).

Commented Issue: Wrong EncodingName in NullCompressor [7670]

reineo — Fri, 31 Aug 2012 07:32:06 GMT

Hi,

I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Comments: The code comes from "Source Code -> Branch -> Latest version". I've just realized the link doesn't point to the latest code base. It seems to be the last stable code according to CodePlex (v 2.2.1.2). That is also the binary version we've been using. I now realize we must use NuGet to get the latest version, including the fix for NullCompressor. So the fix for us is to accuire Combres through NuGet instead of CodePlex :)

Commented Issue: Wrong EncodingName in NullCompressor [7670]

buunguyen — Thu, 30 Aug 2012 16:37:56 GMT

Hi,

I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Comments: This is the code of NullCompressor from the trunk: http://combres.codeplex.com/SourceControl/changeset/view/359a404e315c#Combres%2fEngine%2fCompressors%2fNullCompressor.cs I'm not sure which code version you're looking at, but it must be obsolete.

Commented Issue: Wrong EncodingName in NullCompressor [7670]

reineo — Thu, 30 Aug 2012 06:27:19 GMT

Hi,

I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Comments: Current Combres code base: NullCompressor public string EncodingName { get { return "utf-8"; } } RequestRpocessor.cs => SendOutputToClient response.AppendHeader("Content-Encoding", Compressor.EncodingName); Our current workaround looks like this: NullCompressor public string EncodingName { get { return null; } } RequestRpocessor.cs => SendOutputToClient if (Compressor.EncodingName == null) { response.ContentType += "; charset=utf-8"; } else { response.AppendHeader("Content-Encoding", Compressor.EncodingName); }

Commented Issue: Combres (MVC) when used with MapLowercaseRoute returns 404 for Combres.axd! [7658]

buunguyen — Wed, 29 Aug 2012 19:02:08 GMT

After hours of troubleshooting, it turns out that Comress implementation is case-sensitive. I was using standard sets like siteCss and siteJs - and they would return 404 when translated from Url thats requesting combres.axd/sitecss instead. Changing both to sitecss and sitejs worked a charm.

Please fix - Combres urls shouldn't be case sensitive.
http://xp-dev.com/sc/browse/63550//clubstarterkit/ClubStarterKit.Infrastructure/Routing/MapLowercaseRoute.cs

Comments: Would love to receive a patch

Closed Issue: CSS combine/minify appears to have issues with @import [7656]

buunguyen — Wed, 29 Aug 2012 18:59:09 GMT

I haven't got a great deal of time to investigate this right now, but it appears that when CSS is being combined/minified, @import is not causing the imported files to be included.

I'm using the default configuration, with the only changes made being adding my specific JS/CSS resources, and changes to defaultDebugEnabled and defaultIgnorePipelineWhenDebug.

I was including the CSS resource

<resource path="~/Content/themes/base/jquery.ui.all.css" />

jquery.ui.all.css simply contains

@import "jquery.ui.base.css";
@import "jquery.ui.theme.css";

jquery.ui.base.css simply contains

@import url("jquery.ui.core.css");
@import url("jquery.ui.resizable.css");
@import url("jquery.ui.selectable.css");
@import url("jquery.ui.accordion.css");
@import url("jquery.ui.autocomplete.css");
@import url("jquery.ui.button.css");
@import url("jquery.ui.dialog.css");
@import url("jquery.ui.slider.css");
@import url("jquery.ui.tabs.css");
@import url("jquery.ui.datepicker.css");
@import url("jquery.ui.progressbar.css");

When the pipeline was being invoked, the contents of at least some of the imported CSS files was not being rendered. I searched the rendered CSS for the selector .ui-helper-hidden that occurs in jquery.ui.core.css, and it wasn't present in the rendered code. When I turned off the pipeline, the files were all included correctly and my jQuery UI content was formatted correctly.

I've worked around this issue by directly referencing the files imported by jquery.ui.core.css in combres.xml (in the process excluding some unused CSS files :-).

Btw, thanks for a great tool.
Comments: Fixed

Commented Issue: Wrong EncodingName in NullCompressor [7670]

buunguyen — Wed, 29 Aug 2012 18:58:39 GMT

Hi,

I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Comments: I've checked the code and tested again, NullCompressor doesn't set content-encoding at all. So not sure why you got that content-encoding=utf-8. The current behavior is exactly as you describe: Content-Encoding shuld only be set when compressing the response (i.e gzip).