Open deekoulos opened 3 years ago
Only thing I can think of is if the version number was changed to a version number that previously existed and there were cached files still there (in App_Data/TEMP/ClientDependency) with that version number.
I'm unsure how Umb Cloud sets the CDF number and whether it's done based no a timestamp or just random. The version number changes since that's what is used for the cache busting value for client side assets.
Suppose some null checks can be added to where it is throwing from:
at ClientDependency.Core.CompositeFiles.CompositeDependencyHandler.ValidateRequest(HttpContext context, String& fileKey, ClientDependencyType& type, Int32& version) in C:\Users\Shannon\Documents_Projects\ClientDependency\ClientDependency\src\ClientDependency.Core\CompositeFiles\CompositeDependencyHandler.cs:line 37
which supposedly is here https://github.com/Shazwazza/ClientDependency/blob/master/src/ClientDependency.Core/CompositeFiles/CompositeDependencyHandler.cs#L37
Which would be very odd if any of those are null: context.Request.PathInfo
since I don't see how a request can be null on the HttpContext when this is a .net framework IHttpHandler.
@Shazwazza yesterday I received again 4 more exceptions within the ValidateRequest method, all with the same URL and User Agent. So the version number correction didn't resolve the issue.
Url: https://ourdomain/DependencyHandler.axd
User Agent: (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36)
Exception Message: No query string found in request
at ClientDependency.Core.CompositeFiles.CompositeDependencyHandler.ValidateRequest(HttpContext context, String& fileKey, ClientDependencyType& type, Int32& version) in C:\Users\Shannon\Documents\_Projects\ClientDependency\ClientDependency\src\ClientDependency.Core\CompositeFiles\CompositeDependencyHandler.cs:line 43 at ClientDependency.Core.CompositeFiles.CompositeDependencyHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context) in C:\Users\Shannon\Documents\_Projects\ClientDependency\ClientDependency\src\ClientDependency.Core\CompositeFiles\CompositeDependencyHandler.cs:line 94 at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
just had a new exception with a new user agent:
Unhandled Exception! Url: https://ourdomain/DependencyHandler.axd (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36)
@Shazwazza
This exception still occurs. If I enter the url https://ourdomain/DependencyHandler.axd this exception with the exact same message occurs.
It means, somehow this url is requested automatically.
These are the only mentions of the dependencyHandler.axd in the solution:
ClientDependency.Config
<compositeFiles defaultProvider="defaultFileProcessingProvider" compositeFileHandlerPath="~/DependencyHandler.axd">
<fileProcessingProviders>
<add name="CompositeFileProcessor" type="ClientDependency.Core.CompositeFiles.Providers.CompositeFileProcessingProvider, ClientDependency.Core" enableCssMinify="true" enableJsMinify="true" persistFiles="true" compositeFilePath="~/App_Data/TEMP/ClientDependency" bundleDomains="localhost:123456" urlType="Base64QueryStrings" pathUrlFormat="{dependencyId}/{version}/{type}" />
</fileProcessingProviders>
<!-- A file map provider stores references to dependency files by an id to be used in the handler URL when using the MappedId Url type -->
<fileMapProviders>
<add name="XmlFileMap" type="ClientDependency.Core.CompositeFiles.Providers.XmlFileMapper, ClientDependency.Core" mapPath="~/App_Data/TEMP/ClientDependency" />
</fileMapProviders>
</compositeFiles>
Web.config
<httpHandlers>
<add verb="*" path="DependencyHandler.axd" type="ClientDependency.Core.CompositeFiles.CompositeDependencyHandler, ClientDependency.Core " />
</httpHandlers>
<handlers accessPolicy="Read, Write, Script, Execute">
<remove name="ClientDependency" />
<add verb="*" name="ClientDependency" preCondition="integratedMode" path="DependencyHandler.axd" type="ClientDependency.Core.CompositeFiles.CompositeDependencyHandler, ClientDependency.Core" />
</handlers>
Web.live.xdt.config
<rule xdt:Transform="InsertIfMissing" xdt:Locator="Match(name)" name="Redirects umbraco.io to actual domain" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^(.*)?.s1.umbraco.io$" />
<add input="{REQUEST_URI}" negate="true" pattern="^/umbraco" />
<add input="{REQUEST_URI}" negate="true" pattern="^/DependencyHandler.axd" />
<add input="{REQUEST_URI}" negate="true" pattern="^/App_Plugins" />
<add input="{REQUEST_URI}" negate="true" pattern="localhost" />
</conditions>
<action type="Redirect" url="https://ourdomain/{UrlEncode:{R:0}}" appendQueryString="true" redirectType="Permanent" />
</rule>
If you can reproduce then it should be easy to fix. As mentioned above, some null checks could be added: https://github.com/Shazwazza/ClientDependency/issues/193#issuecomment-759886395
If you have time to submit a PR that would be helpful.
Hello @deekoulos and @Shazwazza, any update/resolution for this issue? I'm having the same problem!
I'm having this issue now also. @deekoulos, @carlosfc-mendes, @Shazwazza have there been any updates on this? Got the error over 2000 times yesterday with the site going up and down.
Hi, this project has not been maintained for many many years. The code will remain here as open source and can still accept PR contributions but the maintainers of the project will not be actively making changes or investigating issues.
If you can reproduce then it should be easy to fix. As mentioned above, some null checks could be added: https://github.com/Shazwazza/ClientDependency/issues/193#issuecomment-759886395
If you have time to submit a PR that would be helpful.
Hi @Shazwazza ,
thanks for your response here: https://github.com/umbraco/Umbraco-CMS/issues/9635 Just for the record, here is the original issue description:
As you mentioned, I recreated the issue here instead, since this is not an Umbraco issue.
I am currently using Umbraco 8.10.1. with CD v1.9.9 and CDMVC5 v1.9.3. So CD is used by its latest version.
The first time this exception was recorder was this week on Monday. So I tried to figure out the possible cause of the issue, by checking the commits right before this Monday.
Here are some findings:
The first time any exception regarding the CD was raised, was on Friday Evening 04.12.2020:
The same exception was repeated one day later. And on 7th December was the first time I recorded the NullReference Exception regarding the CD.
So I checked the commits before the first issue and found out, that on 1st of December (Friday evening) there was an auto upgrade for Umbraco Deploy, which modified the CD Config from:
<clientDependency version="1705826504" fileDependencyExtensions=".js,.css" loggerType="Umbraco.Web.CdfLogger, Umbraco.Web">
to<clientDependency version="1386451558" fileDependencyExtensions=".js,.css" loggerType="Umbraco.Web.CdfLogger, Umbraco.Web">
I dont know if this is causing the issues, but after every Umbraco upgrade, the version numbers of CD were jumping sometimes backwards, sometimes forewards.
I just updated the version number to the last working one +1, and will observe, if the issue is gone.