RequestReduce does not compile css

[code-vj]

RequestReduce not compile any css it show blow exception in dashboard

Exception #1: There were errors reducing http://localhost:57887/cdn/Content/css/scrollable-buttons.css

Stack Trace#2: at RequestReduce.Utilities.WebClientWrapper.Download(String url, IEnumerable1 requiredMimeTypes) in c:\RequestReduce\RequestReduce\Utilities\WebClientWrapper.cs:line 85 at RequestReduce.Utilities.WebClientWrapper.Download[T](String url) in c:\RequestReduce\RequestReduce\Utilities\WebClientWrapper.cs:line 35 at RequestReduce.Utilities.WebClientWrapper.DownloadString[T](String url) in c:\RequestReduce\RequestReduce\Utilities\WebClientWrapper.cs:line 114 at RequestReduce.Reducer.CssReducer.ExpandImports(String cssContent, String parentUrl) in c:\RequestReduce\RequestReduce\Reducer\CssReducer.cs:line 96 at RequestReduce.Reducer.CssReducer.ProcessCss(String url) in c:\RequestReduce\RequestReduce\Reducer\CssReducer.cs:line 64 at RequestReduce.Reducer.CssReducer.ProcessResource(Guid key, IEnumerable1 urls, String host) in c:\RequestReduce\RequestReduce\Reducer\CssReducer.cs:line 38 at RequestReduce.Reducer.HeadResourceReducerBase`1.Process(Guid key, String urls, String host) in c:\RequestReduce\RequestReduce\Reducer\HeadResourceReducerBase.cs:line 37 at RequestReduce.Module.ReducingQueue.ProcessQueuedItem() in c:\RequestReduce\RequestReduce\Module\ReducingQueue.cs:line 162

[dazbradbury]

Hey Matt - I'm getting the same issue on my AppHarbor install now.

It appears when RequestReduce tries to download from: http://[domain]:[port]/

It can't find the content. Now - if I try to access this content in chrome I get the same issue, because appharbor won't let me access the url with the port in place.

RequestReduce appears to be injecting the port here (in my case at least) when re-writing the URL's.

Should I be contacting Appharbor about this, or do you think you can resolve the issue.

Note - I'm running an outdated version of RequestReduce from a few months back, so feel free to tell me to update if you think this has been fixed (wasn't obvious that was the case from the change log though).

Cheers! Daz.

[dazbradbury]

I've fixed this by using the following module:

https://github.com/trilobyte/Premotion-AspNet-AppHarbor-Integration http://nuget.org/packages/Premotion.AspNet.AppHarbor.Integration

[mcintyre321]

daz, are you on the latest? I am getting this isssue, but the Premotion library didn't fix it for me

[dazbradbury]

I actually made the changes in Premotion to v. 0.5. So yes, am using the latest version there.

For RR, I'm using 1.8.32 pulled from NuGet.

The Premotion library should rewrite the url to remove the port number - if this isn't happening, try grabbing the source and including into your project that way. I'm not running it as a package so I can step through and see what is happening.

You can see it is Appharbor's recommendation here:

http://stackoverflow.com/questions/11944236/port-number-in-appharbor-url-causes-page-content-not-to-load

[dazbradbury]

Seems as though if I update to the latest version of RR I get the same issue coming back.

I'm guessing some code has been changed as to how you create absolute urls from relative ones...

After some testing, I can tell you that:

@Request.Url.AbsolutePath => / @Request.RawUrl => / @Request.Url => http://www.openrent.co.uk:15654/

var uri = Context.Request.Url; var baseUrl = new System.UriBuilder(uri.Scheme, uri.Host) { Path = uri.PathAndQuery }.Uri;

@baseUrl => http://www.openrent.co.uk/

@Request.Url.AbsoluteUri => http://www.openrent.co.uk:15654/

It might be best if I pull down the RR source and integrate it into my app that way - rather than using it as a package, but I can see that just using AbsoluteUri still causes my URLs to be generated with their port number.

Does anyone know of a way to permanently override this behaviour? I've checked all my server variables, and they are set correctly (ie. port 80 or 443 only). I also can't see the source for Request.Url and the others mentioned above, which makes overriding their behaviour somewhat difficult.

Any ideas would be appreciated!

[dazbradbury]

OK - so it seems this commit was part of the problem:

https://github.com/mwrock/RequestReduce/commit/728ee6c209e859a6d0dad83ef3b638e7535f7409

I reverted all the changes in:

/RequestReduce/Handlers/FlushHandler.cs /RequestReduce/Handlers/ReducedContentHandler.cs /RequestReduce/Module/RequestReduceModule.cs

I also updated this line:

https://github.com/mwrock/RequestReduce/blob/master/RequestReduce/Module/ResponseTransformer.cs#L63

to:

var uri = context.Request.Url;
var url = relativeToAbsoluteUtility.ToAbsolute(new System.UriBuilder(uri.Scheme, uri.Host).Uri, urlMatch.Groups["url"].Value);

And now it seems to be working perfectly... Obviously, this may cause issues elsewhere, so I don't want to offer a pull request, but it might help work out what the issue is for us Appharbor users!