Beim Aufsetzen eines Reverse-Proxies gilt es im Zusammenspiel mit XPage-basierten Web-Applikationen ein Detail zu ber\u00fccksichtigen: F\u00fcr die Implementierung des Partial Refresh-Mechanismus mu\u00dfte ein zus\u00e4tzlicher HTTP-Header eingef\u00fchrt werden, durch den u.a. Redirects an den Webbrowser gesteuert werden.<\/p>\n
Da im Zusammenspiel mit AJAX-basierten Aktionen wie dem Partial Refresh nicht mit vom Server gelieferten HTTP-Responsecodes (302 bzw. 307)\u00a0 gearbeitet werden kann, wird der HTTP-Response der HTTP-Header „X-XspLocation“ angeh\u00e4ngt.<\/p>\n
Beim \u00d6ffnen eines Server-seitigen Links wird so dem Browser mitgeteilt, wohin die Reise geht, und die eigentliche Umleitung wird Clientseitig (via JavaScript) durchgef\u00fchrt. Wird der Header also nicht durch die Regeln im Reverse-Proxy \u00fcberarbeitet, funktioniert die Applikation h\u00f6chstwahrscheinlich nicht.<\/p>\n
Hier ein kurzes Beispiel und die HTTP-Daten, die durch Klicken auf den Link gesendet werden.<\/p>\n
<\/span><xp:link escape=\"true\" id=\"link1\" text=\"ServerSideLink\">\r\n <xp:eventHandler event=\"onclick\" submit=\"true\"\r\n refreshMode=\"norefresh\" execMode=\"partial\">\r\n <xp:this.action>\r\n <xp:actionGroup>\r\n <xp:openPage name=\"\/XPage2Open.xsp<\/strong>\" \/>\r\n <\/xp:actionGroup>\r\n <\/xp:this.action>\r\n <\/xp:eventHandler>\r\n<\/xp:link><\/pre>\nHTTP Request (Client an Server)<\/span><\/h4>\nPOST \/xpage.nsf\/current.xsp?$$ajaxmode=full&$$ajaxid=%40none HTTP\/1.1\r\nHost: blog.hasselba.ch\r\nUser-Agent: Mozilla\/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) ...\r\nAccept: text\/html,application\/xhtml+xml,application\/xml;q=0.9,...\r\nAccept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3\r\nAccept-Encoding: gzip, deflate\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r\nContent-Type: application\/x-www-form-urlencoded; charset=UTF-8\r\nX-Requested-With: XMLHttpRequest\r\n<\/strong>Referer: https:\/\/blog.hasselba.ch\/xpages.nsf\/current.xsp\r\nContent-Length: 306\r\nCookie: DomAuthSessId=XXXXX; SessionID=XXXX\r\nPragma: no-cacheCache-Control: no-cache<\/pre>\n[Fett hervorgehoben: Standard-Header bei AJAX-Requests]<\/em><\/p>\nHTTP Response (Server an Client)<\/span><\/h4>\nHTTP\/1.1 200 OK\r\nServer: Lotus-Domino\r\nDate: Thu, 09 Jun 2011 06:22:56 GMT\r\nX-XspLocation: http:\/\/blog.hasselba.ch\/xpages.nsf\/XPage2Open.xsp<\/strong>\r\nContent-Length: 20\r\nConnection: Keep-Alive\r\nContent-Encoding: gzip<\/pre>\n[Fett hervorgehoben: Der Header mit dem neuen Ziel. Der Client \u00f6ffnet die Seite via JavaScript]<\/em><\/p>\n <\/address>\n <\/address>\n","protected":false},"excerpt":{"rendered":"Beim Aufsetzen eines Reverse-Proxies gilt es im Zusammenspiel mit XPage-basierten Web-Applikationen ein Detail zu ber\u00fccksichtigen: F\u00fcr die Implementierung des Partial Refresh-Mechanismus mu\u00dfte ein zus\u00e4tzlicher HTTP-Header eingef\u00fchrt werden, durch den u.a. Redirects an den Webbrowser gesteuert werden. Da im Zusammenspiel mit … Weiterlesen