locked
"Request no browser caching" breaks OWA? RRS feed

  • Question

  • I set up a new UAG 2010 SP1 installation, published OWA 2010 (sp1 update 2) exchange org, and tested OWA.  It worked very well, of course then I show it to a user and he immediatly uploads a document into an email, sends it to himself, and then tries to open it.  Blam, nice big fat error. 

    Unable to download attachment.ashx from fqdn.

    I was able to right click and "Save Target As" and I was able to "Open as Web Page", but if you simply click the file you recieve that error. Fixing it was simply a matter of unchecking the "Request no broswer caching" check box.  I know it uses the vary header to request no browser caching, but I assumed that doing would leave no traces behind verses restrict in-session client functionality. 

    Is this working as designed or is it a bug?  Not sure if it's my understanding that needs to evolve of how the 'request no browser caching' works, or if it should be working and this is just a minor bug?

    J.


    If it was helpful, vote for it. If it answered your question, mark it as answered. Small thing to do for free help from a strong community :)
    Wednesday, March 2, 2011 1:17 PM

Answers

  • Hi J.

    I do not think this would/could qualify as a bug, but rather as "working as design". Certainly not a UAG bug. When the UAG administrator has configured UAG to use what could be considered as an additional security measure - "Request no browser caching", UAG does just that. As you correctly pointed out, the result of this configuration option is that UAG adds a "Vary" header to each HTTP response it sends to the browser. Normally, a browser would download an attachment from an OWA email into its Temporary Internet Files folder, and then that file is opened for viewing. In your scenario, due to the addition of the Vary header, the browser complies and does not store the attachment file in the Temporary Internet Files folder, and therefore fails when attempting to open the non-existing file.

    BTW, this is why "Request no browser caching" is not enabled by default in a UAG trunk, and wiping the browser's cache is done by the UAG Endpoint Session Cleanup component (obviously, if the UAG components were installed, and if the "Activate Endpoint Session Cleanup" option is enabled, which, by default, it is).

    Regards,


    -Ran
    Wednesday, March 9, 2011 2:44 PM

All replies

  • Hi J.

    I do not think this would/could qualify as a bug, but rather as "working as design". Certainly not a UAG bug. When the UAG administrator has configured UAG to use what could be considered as an additional security measure - "Request no browser caching", UAG does just that. As you correctly pointed out, the result of this configuration option is that UAG adds a "Vary" header to each HTTP response it sends to the browser. Normally, a browser would download an attachment from an OWA email into its Temporary Internet Files folder, and then that file is opened for viewing. In your scenario, due to the addition of the Vary header, the browser complies and does not store the attachment file in the Temporary Internet Files folder, and therefore fails when attempting to open the non-existing file.

    BTW, this is why "Request no browser caching" is not enabled by default in a UAG trunk, and wiping the browser's cache is done by the UAG Endpoint Session Cleanup component (obviously, if the UAG components were installed, and if the "Activate Endpoint Session Cleanup" option is enabled, which, by default, it is).

    Regards,


    -Ran
    Wednesday, March 9, 2011 2:44 PM
  • Yes butttttttttttttttttt ........... ;)

     

    Hi Ran,

    I just finshed now an UAG project and I discovered this scenario. But AFAIK in many UAG/OWA projects, we define corporate device as priviliged and can download and others will not be able to download.

    ere in my case, I tick the option "Request no browser caching" only for default session, and NOT for Privileged session. But, when I was connected with a priviliged computer, I had the error "Unable to download attachment.ashx from fqdn", but I was able to right click "Save As" option working.

    By design in this case ? "Request no browser caching" for default session can overwrite privileged parameters ?

     

    Regards,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Wednesday, August 24, 2011 2:12 PM
  • Hi Giraud,

    you can figure out what happend exactly by using fiddler. If UAG is sending the "VARY" header even in the case being a priviledged endpoint then it might be a UAG glitch. But if UAG doesnt send the Header the problem you still experience may be releated to your client...

    -Kai

    Wednesday, August 24, 2011 3:49 PM