none
Disable HAT or other AJAX strategies RRS feed

  • Question

  • We're using DotNetNuke as an internal documentation portal of sorts.  UAG correctly publishes and SSO's the application, and all seemed great until we started hitting some of the more advanced parts of the portals that use AJAX calls.


    Here's what is happening:

    On a page with an AJAX call we get this error in IE and Firefox (although Firefox hides it in the error log by default):

    Error: Sys.ScriptLoadFailedException: The script 'https://sub.contoso.com/DNNPortal/Resources/Shared/scripts/initWidgets.js' could not be loaded.
    Source File: https://sub.contoso.com/uniquesigd2c572b4a1c65f90c8320e272bca7a29fa766152bc2e988b7262cc59b4199cea6d9058fbab69f99dbaf11a25515642d3/uniquesig1/DNNPortal/ScriptResource.axd?d=7Ja4_b1r8R8SA6876VUaxlxngSbOaU6DVT-HnP_QutYki_9pdYEh9cZDCHFf7-TVaxtq6F0x6XsYZ2O-pXaiGwlajQaaIFp30&t=ffffffffec2d9970
    Line: 5


    The URL that it claims couldn't be found actually hits and redirects perfectly when using a browser to address it directly.

    Using fiddler to review the traffic I can see that the page call itself never ends up with a 200 status though, the traffic is a simple 1-2.

    HTTP/1.1 302 Object Moved - https://sub.contoso.com/DNNPortal/Resources/Shared/scripts/initWidgets.js

    HTTP/1.1 304 Not Modified - https://sub.contoso.com/uniquesigd2c572b4a1c65f90c8320e272bca7a29fa766152bc2e988b7262cc59b4199cea6d9058fbab69f99dbaf11a25515642d3/uniquesig1/DNNPortal/Resources/Shared/scripts/widgets.js

    I'm assuming the browser/javascript engine is erroring on a not-found because of the 304 status that is returned instead of a 200 status.  What options are available with UAG to accomodate AJAX requests of this sort?
    Saturday, May 29, 2010 1:16 AM

Answers

  • Hi Ran,

    No I had not tried that as I wanted all applications to use the same hostname as we're trying to go 100% ssl on this and another hostname means more consideration to certificates.  However it is good to know that HAT will be disabled in that scenario and that a seperate hostname/cert adjustments are simply the cost of doing so.

    This issue is resolved now without having to modify UAG, but I'll share the solution for web searchers and anybody else that may be interested.  A lot of searching and digging told me two things:

    If the browser/ajax is to spec it treats 302's as 200's and that is what DNN/IE/Firefox are doing.

    If the javascript is to spec it notifies the browser when it's done loading, and that is what DNN is NOT doing.

    I customized the .js file (initWidgets.js) throwing this error by appending the following to the very bottom of the file:

    if( Sys && Sys.Application ){
       Sys.Application.notifyScriptLoaded();
    }

    The errors have now stopped and everything runs as it should.

    The above javascript forces a notification to the browser that the script loaded successfully.  Apparently IE and Firefox both automatically catch when a script is done, which is why it works fine under normal circumstances.  My guess is that the redirection mucks up the auto-detection and so the script failing to notify the browser was brought to light.
    • Proposed as answer by Ran [MSFT] Saturday, May 29, 2010 5:55 PM
    • Marked as answer by Zachary Cook Saturday, May 29, 2010 9:05 PM
    Saturday, May 29, 2010 5:06 PM

All replies

  • Hi Zachary,

    have you tried publishing the same app using the Application Specific Hostname template in UAG, instead of the Portal Hostname template? That way, HAT will not be used to rewrite the links in your application and that might solve the issue.

     

    -Ran

    Saturday, May 29, 2010 8:19 AM
  • Hi Ran,

    No I had not tried that as I wanted all applications to use the same hostname as we're trying to go 100% ssl on this and another hostname means more consideration to certificates.  However it is good to know that HAT will be disabled in that scenario and that a seperate hostname/cert adjustments are simply the cost of doing so.

    This issue is resolved now without having to modify UAG, but I'll share the solution for web searchers and anybody else that may be interested.  A lot of searching and digging told me two things:

    If the browser/ajax is to spec it treats 302's as 200's and that is what DNN/IE/Firefox are doing.

    If the javascript is to spec it notifies the browser when it's done loading, and that is what DNN is NOT doing.

    I customized the .js file (initWidgets.js) throwing this error by appending the following to the very bottom of the file:

    if( Sys && Sys.Application ){
       Sys.Application.notifyScriptLoaded();
    }

    The errors have now stopped and everything runs as it should.

    The above javascript forces a notification to the browser that the script loaded successfully.  Apparently IE and Firefox both automatically catch when a script is done, which is why it works fine under normal circumstances.  My guess is that the redirection mucks up the auto-detection and so the script failing to notify the browser was brought to light.
    • Proposed as answer by Ran [MSFT] Saturday, May 29, 2010 5:55 PM
    • Marked as answer by Zachary Cook Saturday, May 29, 2010 9:05 PM
    Saturday, May 29, 2010 5:06 PM
  • Glad you resolved it and thanks for sharing the solution.

    Regards,

    -Ran

     

    Saturday, May 29, 2010 5:56 PM