Finaly I was able to get IE to do it correctly :-) There is an update on http://beta.woodstone.nu (beta dot woodtone dot nu).
Apparently the redirect that is done to saweb once you clicked on the link, has to have the cache-control part too and not just the saweb page itself. Dirk. -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of dirk Sent: Wednesday, July 08, 2015 9:45 PM To: Servers Alive Discussion List Subject: RE: [SA-list] SAWeb behavior Just to let you know I'm still trying to find a solution for this. Normaly if the server (SA) would send a "Pragma: no-cache" statement then IE shouldn't cache it and it should work. However the webserver control that we're using is somehow changing it to "pragma: no-cache" (lowercase p instead of uppercase P). Based on the RFC it should be an uppercase P. So I'm now trying to get the developper of the component to admit there is an issue and to fix it (should be possible knowing the guy :-)) Once I have that fix I can test more to see IF that solves the issue with IE. Via the template you can have the active/maintenance "link" too. BUT I think it will have the same issue as you see with saWeb now too. Give me a few hours/days to get this webserver component fixed and then I can go further and see if that also fixes the caching issue (by setting Pragma and not pragma). Dirk. -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Turner, Peter Sent: Wednesday, July 08, 2015 9:35 PM To: Servers Alive Discussion List Subject: RE: [SA-list] SAWeb behavior >>> Not sure how I can solve this IE issue via SA..... I don't disagree. I have now tried on a desktop with firefox and it operates as I would expect. Unfortunately we can't really use Firefox - don't have it installed on my desktop ( most desktops here) 'cause our PACS needs IE and with FireFox installed IE can no longer run PACS - no doubt another IE quirk. My first statement was: >>> I don't think it is anything with SAWeb per se, because I can fire >>> off a wget and switch an item to and from maintenance - just about >>> has to be some 'save me from myself' feature of IE. >>>So somehow IE is something weird in the caching That probably explains why it would work when I used FQDN instead of hostname - just cached a different url. Just some background as to what I was trying to accomplish. This set of devices, and the template generated web page will be monitoring number of devices on a drug dispensing system. I wanted the functionality for the pharmacy to be able to set a device to maintenance if they were going to take it off line. I had all the parts in place - it was a little clunky because it kicked open the SAWeb page rather than just do the action but at least they could have had ability to turn off and on as needed. Can you think of any other way to skin that cat: Allow users to control Active/Maintenance via the template. <TD><FONT face="verdana" Size="1"><Center> <saif sa_status is maintenance><a href="http://amber2.famhs.org/saweb?uid=<sa_uid>&active=true" target="_blank">Set Active</a></saif> <saif sa_status not maintenance><sa_checkresponse>-<sa_stats_uptime> <a href="http://amber2.famhs.org:4310/saweb?uid=<sa_uid>&active=false" target="_blank">Set Maintenance</a></saif> </Center></FONT> </TD> Bottom line - I will live with it. I appreciate you digging into the problem. Thank you. IT-Works on site @ Fort HealthCare [email protected] | Sr Sys Integration Architect | Fort HealthCare | O:920-568-5137 | C:414-861-7205 or 414-467-7543 | www.forthealthcare.com -----Original Message----- From: dirk [mailto:[email protected]] Sent: Wednesday, July 08, 2015 1:21 PM To: Turner, Peter Subject: RE: [SA-list] SAWeb behavior As you can see what is received (and send?) by Servers Alive is 00000179238.56903076[4340] saWeb : /saweb -> no parameters at all 00000217301.86190796[4340] saWeb : /saweb?uid=3018&active=false 00000218301.86218262[4340] saWeb : active=false (3018) -> parameter is received and the change is done I just did some testing on my system and I'm unable to reproduce the problem when using Firefox. However when using IE I do get the issue. Which is strange as in both cases the same "page" is generated, with the same links. I tried it via a remote system (using IE) and when I look at a network trace, I can see that IE is NOT sending the correct URL. The URL that IE "sends" to the SA system is just http://cp.mcafee.com/d/avndygAd3gQrhopsp76zBNNUTsSehKCed7b29IsztcsqenAPoV6Wo UQsI9CNOdQNNEVu76RLDYuCT67N1jJoP9SVsSXmcOtKndEEWUwqenT-LOdTD3hOeuWZOWqtPhPOq qr8WZ-mKDp55mXzDaxVZicHs3jq9JwTvAm4TDNOb2pEVdTdw0UqHWj3adYFE0zq4EBgkoHl2AWM_ EdCT4m4Pob6Azh0qmNwgbDOFcQKCy0o405Ywq827AZcOH4SCYrQwxbYKfI without any parameter. So it's "normal" that SA isn't doing anything else then showing saWeb when receiving that URL. It's seems to be some type of issue in IE. (I tried it with both the "default" IE that is installed on Win2008R2 and on Win7). What I can reproduce is that I connect to saWeb and change the status twice (from active to maintenance and from maintenance to active), and then it will always just call "saweb" without any parameters. If I go into the Internet Options and clear the "Temporary Internet file and website files", and then try again (even without restarting IE) it works again for 2 calls. So somehow IE is something weird in the caching. Even when adding headers to say that the webbrowser should NOT cache the content, IE is doing it somehow. Not sure how I can solve this IE issue via SA..... dirk ________________________________ CONFIDENTIALITY NOTICE: The information transmitted above is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you have received this message in error, please contact the sender or the Information Systems Department at Fort HealthCare, (920) 568-5132. Thank you. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
