Big error 404 file not found

Mar 4, 2014 at 9:10 AM
Hi this morning with my client I discover a big big problem.
In the admin back office is impossible to update articles, I receive always a 404 error

dnn 7.1.2 nbstore 2.3.8

Any one have the same problem? can you help me.
I try to resolve with the encoding url hack or umanfriendly in web.config but nothing!

Mar 4, 2014 at 10:16 AM
Yes, I think I saw this on a test system, as I recall updating the web.config to “humanfriendly” solved it for me…do you find that doesn't work??

what url is it?
Mar 4, 2014 at 10:47 AM
Edited Mar 4, 2014 at 10:58 AM
Can I send you a private admin user?


can you tell me the modify you have made to the man friendly on the web.config
in my web.config I don't have humanfriendly key?!?

The error appear when:
  • In the category page I click to another category in the category tree
  • in the product page I press update or cancel
I don't think it's a skin path encoding problem
On the category page one of my url is

If i delelte the sking part

I'm redirect to the same module on the mail skin and here if i press on another category i receive a 404 error

Mar 4, 2014 at 10:54 AM
Look for the following in the web.config:
    <friendlyUrl defaultProvider="DNNFriendlyUrl">
        <clear />
        <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="humanfriendly" />
where the above reads urlFormat="humanfriendly" your existing entry probably is set to urlFormat="advanced"

Advanced causes several problems including what you have described.
Mar 4, 2014 at 11:14 AM
Hi Technica thanks but your solution don't solve my problem!
I think that isn't a url problem.....
Mar 4, 2014 at 11:23 AM
You may have to clear the browser cache when changing the urlFormat for the change to work.
Mar 4, 2014 at 11:30 AM
If you change the %2f in the url parameter to / does that solve the 404 error?

for example enter the following in your browser:

if the admin pages do display then it looks very much like the urlFormat is set to "Advanced" and needs to be changed to "Humanfriendly", but you may need to clear the browsers cache once the change has been made.
Mar 4, 2014 at 11:31 AM
oh! my god

I find the solution and i don't understand why but

last week i try to enlarge the maximum upload for the file to 30Mb

i modify the web config adding in system.webServer
        <requestLimits maxAllowedContentLength="30720" />
and modify
<httpRuntime shutdownTimeout="120" executionTimeout="900" useFullyQualifiedRedirectUrl="true" maxRequestLength="12288" requestLengthDiskThreshold="12288" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\,?" requestValidationMode="2.0" />
<httpRuntime shutdownTimeout="180" executionTimeout="900" useFullyQualifiedRedirectUrl="true" maxRequestLength="30720" requestLengthDiskThreshold="30720" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\,?" requestValidationMode="2.0" />
restoring the old web.config all go well!!!!
But I'm interested to know why is possible that this can make this error!!!!!!
very strange
but I have solved!
Thanks for all your support!
Mar 4, 2014 at 12:45 PM
I think maybe changing the web.config caused a clearing of all cache and started the humanfriednly url..

I have this on my dev website ..
<httpRuntime shutdownTimeout="520" executionTimeout="1900" useFullyQualifiedRedirectUrl="true" maxRequestLength="1228800" requestLengthDiskThreshold="1228800" requestValidationMode="2.0" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,\,?" />
And it's working fine. So I think it was the urlrewriter,, you can test that by moving back to advanced (If you dare!!! :-) ) My thought is that the advanced option should never have been made the default! For 95% of clients the humanfriendly is OK, it's over zealous SEO bods that make the advanced option a must for the Evoq platform....testing it out on the DNN platform might seem the right business thing to do for DNN, but it's a pain in the butt!