locked
AppWrapper to handle a relative URL RRS feed

  • Question

  • Hi there folks

    Have an issue with a client accessing an application on a web sever through UAG.  When the web page presents a JavaScript it does so with a number of relative URL, some of which have a leading / and some which don't.  When the results come back the relative URLs with a leading / are HAT'd as you would expect but the ones which don't have a leading / are not HAT'd.

    The results look like this:

    With leading / :

    <script src="/application/File.axd?d=W9UFrsywSzaixt600WSKP6aaTR5jY8aGwdPJpgtDxvzbduFxt_OVn1FPbz_zGiyBPjAq0fDsGgK1iN_7SAL5sCLsDX01&amp;t=634259066654344891" type="text/javascript"></script>

    Without leading / :

    <script src="folder/File.asmx/js" type="text/javascript"></script>

    How do we go about AppWrappering this so that we see a leading / AND the signature?

    Thursday, August 9, 2012 3:56 PM

All replies

  • Hello Alter-Ego,

    The UAG should not add the HAT signature to relative URLs, because the browser should "convert" the relevant URL into full URL based on the page that generate that link. For example, if in your scenario, the page that generate the above code was https://uag/HAT/directory/page.ext the browser will "convert" this relative URL to https://uag/HAT/directory/folder/file.asmx/js. You can use fiddler or the built-in F12 tool (in case of IE9 and above) to see what is the full URL that the browser requesting and based on that decide how to fix the issue, but just adding HAT to relative URLs is not the best solution, as this may cause "double-hat" in case the page source is already HATed (as usually expected).

    Ophir.

    Thursday, August 9, 2012 4:39 PM
  • Thanks for the response.  I think I'm a bit more confused than before now!

    What we are seeing is that the web page appears to be downloaded OK but there are some buttons which you click on and it errors - we get a 500 message generated by the server.  I must admit that it's an assumption that the relative URLS are the ones causing the problem

    Thursday, August 9, 2012 8:21 PM
  • Do you know if the error 500 is arriving with http status 500 or 200 (should see in the fiddler)?

    If it is 200, it possible it is a "fake" error 500 error coming from the UAG, and this usually mean the backend server is not reachable.

    Also, if it is just generic "Internet Explorer cannot display the webpage" error, and not error 500, it can be the link does not get translated and the browser try to access the internal hostname. In this case, right-click on the page and choose "properties" may help identify it.

    Friday, August 10, 2012 4:41 AM