Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Andreas Pfanner 196 posts 314 karma points
    Feb 24, 2015 @ 18:36
    Andreas Pfanner
    0

    Umbraco Forms 4.0.1 on Umbraco 7.2.2 - This operation is not supported for a relative URI.

    Hi,

    I've installed the current release of Umbraco Forms to Umbraco 7.2.2. On my local dev machine it works fine, but on the web server it doesnt. In the backend on the Forms dashboard I only see placeholders like {{overlay.title}}. I figured out that one call to DependencyHandler.axd throws a 500: "This operation is not supported for a relative URI."

    Whats the problem on the web server?

    Best Regards Andreas

  • Jan Skovgaard 11280 posts 23678 karma points MVP 11x admin c-trib
    Feb 24, 2015 @ 21:21
    Jan Skovgaard
    0

    Hi Andreas

    What is your local setup versus your server setup? Any differences in regards to the software being used, configurations etc. ? I have seen another post about this as well but not sure why it happens.

    /Jan

  • Andreas Pfanner 196 posts 314 karma points
    Feb 25, 2015 @ 08:50
    Andreas Pfanner
    0

    Hi Jan,

    my local environment is under source control (TFS) using Visual Studio 2013 on IIS 8. The server is 2008 R2. All the other parts (as far as I've seen) work on the server.

    What I did: - Installed the Umbraco Forms package using local package on my local environment - Added the files contained in the package (AppPlugins, Views,..) to my solution / source control - Published the whole project (WebDeploy) to the Web server, which copied the Umbraco Forms files as well to the Web server - I also tried to manually copy the AppPlugins from local to server, so the contents there are identical. web.config is too.

    Where can I search / compare? What parts are responsible for the errors?

    Best Regards Andreas

  • Andreas Pfanner 196 posts 314 karma points
    Feb 25, 2015 @ 12:41
    Andreas Pfanner
    0

    Hi again,

    I've compared the two instances step by step, and found out that one setting in web.config is different. On my local machine, I have set

    <compilation debug="true" .../>
    

    which wasn't set at the server. Turning debugging on at the server as well solves the issue. Pretty weird, isn't it?

    Best Regards Andreas

  • Jan Skovgaard 11280 posts 23678 karma points MVP 11x admin c-trib
    Feb 25, 2015 @ 15:56
    Jan Skovgaard
    0

    Hi Andreas

    Ok, you should not need to have debug set to true on the server. It should be set to false once the site is live.

    Don't know if you have tried to clear the Umbraco backoffice cache by going to the /config/ClientDependency.config file and increment the version attribute and then recycle the app pool?

    Also double check that all required files are deployed as well - But I suspect it's the backoffice cache that is playing a trick on you.

    Fingers crossed.

    /Jan

  • Andreas Pfanner 196 posts 314 karma points
    Feb 26, 2015 @ 14:57
    Andreas Pfanner
    0

    Jan, I already thought about that and tested it, but to be sure, I've just done that again:

    On the server: - Setup debug="false" in web.config -> Breaks Umbraco Forms backend - increased version in ClientDependency.config, Recycle - No difference, Umbraco Forms backend still broken - Set debug="true" in web.config -> Umbraco Forms Backend works fine

    I really wonder how the debug flag can make these differences, but I can absolutely reproduce it by switching.

    Best Regards Andreas

  • Jan Skovgaard 11280 posts 23678 karma points MVP 11x admin c-trib
    Feb 26, 2015 @ 16:23
    Jan Skovgaard
    0

    Hi Andreas

    It has to do with handling backoffice assets that are cached/minified/handled using ClientDependency I think. It's checking on this attribute and acts different depending on if you're on a local environment where it's true or in a live environment where it should be set to false.

    But perhaps there is an issue in general with this when dealing with Forms - It might be worth adding an issue to the issue tracker about it then.

    Hope this helps.

    /Jan

  • Andreas Pfanner 196 posts 314 karma points
    Mar 16, 2015 @ 15:11
    Andreas Pfanner
    101

    Hi Jan, hi all,

    finally I was able to solve that issue. I turned debug to false in web.config, which broke the Umbraco Forms backend (as expected). Then I looked through all Package.Manifest files in the App_Plugins directory. I found that one package (uTagsy) used a query string parameter in the manifest urls. Removing this brought back the Umbraco Forms backend.

    Best Regards Andreas

  • Matthew Kirschner 323 posts 611 karma points
    Mar 16, 2015 @ 16:44
    Matthew Kirschner
    0

    I'm having the same issue as Andreas.

    I don't have uTagsy installed, but there must be some package I have that is using a query string (I'm looking at manifests now). Is that really the issue? Are query strings not supported with ClientDependancy?

    Thanks, Andreas, for pointing this out.

  • Andreas Pfanner 196 posts 314 karma points
    Mar 17, 2015 @ 09:35
    Andreas Pfanner
    0

    Hi Matthew,

    I guess it can have to do with an updated version of ClientDependency (see http://umbraco.com/follow-us/blog-archive/2015/2/5/security-alert-update-clientdependency-immediately), which is more strict than it was in previous versions. I think that others solved that error using a previous version of ClientDependency.dll (where I prefer to remove the query strings instead). But I haven't analyzed this further.

    It would also explain why it works with debug="true" - then ClientDependency seems to be less strict and allows these querystrings.

    Best Regards Andreas

  • Rune Grønkjær 1372 posts 3103 karma points
    May 18, 2015 @ 14:07
    Rune Grønkjær
    0

    Looks like the problem is with the javascript files in the manifest files. Found the answer here: http://umbraco.com/follow-us/blog-archive/2015/2/5/security-alert-update-clientdependency-immediately

    Patrick Scott's answer is spot on:

    I know this blog is a little old, but I have found a fix for "This operation is not supported for a relative URI".

    Look through the App_Plugins folder for package.manifest files. Ensure that all of the URLs in those files do not have a querystring on the end e.g. something like "?v=abcd".

    These querystrings are not needed, so should not break these packages.

Please Sign in or register to post replies

Write your reply to:

Draft