It seems that msdn's archives were reorganised slightly. you can now find the ISAPI plugin mentioned at: http://blogs.msdn.com/b/david.wang/archive/2005/09/28/howto-isapi-filter-which-logs-original-client-ip-for-load-balanced-iis-servers.aspx ... View more

Hi Ranjan,   Sorry for the late reply.  Looking through the Stingray Control API documentation found here:   https://support.riverbed.com/download.htm?filename=public/doc/stingray/developer_edition/Stingray_9.0_Control_API.pdf   There is clearMatchingCacheContent (protocol, host_wildcard, path_wildcard), so try something like:   clearMatchingCacheContent('http', "abc.com", "static/image.gif"); clearMatchingCacheContent('https', "abc.com", "static/image.gif");   or   clearMatchingCacheContent('both', "abc.com", "static/image.gif);   To cover both http and https.  Hope this helps.   Thanks, Faisal ... View more

The Payment Card Industry, including Visa and Mastercard, require banks, merchants and Member Service Providers to protect cardholder information by adhering to a strict set of security standards. The Payment Card Industry security standard (PCI) includes MasterCard's Site Data Protection (SDP) program and Visa's Cardholder Information Security Program (CISP). Selecting the SSL and TLS ciphers and protocols used To fully comply with the security standards outlined by the Payment Card Industry you will need to restrict the SSL ciphers and protocol versions that ZXTM allows clients to use: Disabling SSL version 2 in ZXTM Enabling TLS 1.0 and 1.1 in ZXTM Disabling SSL2 in the Zeus Admin Interface Disabling Weak SSL3 Ciphers in the Zeus Admin Interface Disabling Weak SSL3 Ciphers in ZXTM Navigate to: SYSTEM > GLOBAL SETTINGS > SSL CONFIGURATION ZXTM's Cipher List Enter the below ciphers: SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_AES_256_CBC_SHA: SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_AES_128_CBC_SHA Disabling SSL version 2 for client connections in ZXTM Navigate to: SYSTEM > GLOBAL SETTINGS > SSL CONFIGURATION Disable the setting ssl!support_ssl2. SSL version 2 has known weaknesses. Enabling TLS 1.0 and 1.1 in ZXTM Navigate to: SYSTEM > GLOBAL SETTINGS > SSL CONFIGURATION Enable the settings ssl!support_tls1 and ssl!support_tls1.1. Disabling SSL2 in the Zeus Admin Interface In $ZEUSHOME/admin/global.cfg enter: tuning!support_ssl2 no Disabling Weak SSL3 ciphers in the ZXTM Administrator Interface In $ZEUSHOME/admin/global.cfg insert, on one continous line: tuning!ssl3_ciphers SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_AES_256_CBC_SHA: SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_RSA_WITH_AES_128_CBC_SHA Please remember to re-start your admin server. We recommend using: $ZEUSHOME/admin/rc restart ... View more

Hello,   WebLogic Integration (WLI) is a comprehensive, standards-based solution that unifies all the components of business integration – business process management, data transformation, trading partner integration, and user interaction – in a flexible, easy-to-use environment.   Follow the below steps for WebLogic Integration   Get Started Overview of WebLogic Integration Using the Domain Configuration Wizard Using the Domain Template Builder WebLogic Domain Template Reference Solution Samples Develop WLI Applications   Thanks.   Link Removed by Admin @jason_cmgr ... View more

Overview Increasingly, our modern-day workforce requires upward-mobility. It follows that a businesses infrastructure requirements are radically changing to suit their employees' needs. Zeus' Extensible Traffic Manager was designed to co-exist in a mobile environment; sustaining, securing and accelerating the infrastructure a work-force requires to reliably conduct business day-to-day. Infrastructure software widely deployed to assist with a business' work-mobility is <a target="_blank" href="http://www.microsoft.com/exchange/en-us/mobile-email-with-exchange-activesync.aspx">Microsoft's Outlook Web Access</a> . Integration with ZXTM Outlook Web Access can be quickly, easily and securely integrated into ZXTM. We recommend that you allow ZXTM to handle the SSL decryption; reducing the cpu stress to your Exchange back-end(s). A HTTP protocol server, listening on port 443, should be setup to handle traffic to your Exchange server. ZXTM will now take care of the rest! WebDAV Conformity, Exchange and SSL Decryption Zeus has discovered a requirement to implement a trafficscript solution in situations where a non-standard WebDAV resource is invoked. RFC2518 states that: There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names. In certain circumstances, a client will issue a request for /exchange instead of /exchange/ . As per the RFC, a webserver will correctly respond by issuing a <a target="_blank" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2">301 object permanently moved</a> header. Let us confirm this by using httpclient . [email protected]# ./httpclient -m HEAD http://www.zeus.com/about HTTP/1.1 301 Moved Permanently Vary: Accept-Encoding Connection: close Content-Length: 212 Date: Sun, 23 Jul 2006 03:51:38 GMT Location: http://www.zeus.com/about/ A client request complete with a trailing slash meets with a different server response code: [email protected]# ./httpclient -m HEAD http://www.zeus.com/about/ HTTP/1.1 200 OK In normal circumstances, a client receiving a http 301/302 status code would transparently obey the instruction and a correct GET request issued, complete with trailing slash. With ZXTM performing its magic and taking care of all SSL transactions, a back-end Exchange server is now only HTTP aware. As a consequence, the re-direct issued by Microsoft IIS will be a HTTP based URI. IIS is acting perfectly correctly, but unfortunately the request by the client will not succeed as an Exchange server is often only configured for secure (HTTPS) connections. To confirm this, let's make a HTTP request to a secure site with ZXTM in front, performing SSL-decryption, but without a trailing slash. If what we have talked about above is correct, we will see a Location: banner for a (non-secure) HTTP re-direct. [email protected]:# ./httpclient -m HEAD -3 <a target="_blank" href="https://www.zeus.com/internal-test">https://www.zeus.com/internal-test</a> HTTP/1.1 301 Moved Permanently Content-Length: 212 Date: Sun, 23 Jul 2006 04:05:11 GMT Connection: close Location: <a target="_blank" href="http://www.zeus.com/internal-test/">http://www.zeus.com/internal-test/</a> So, our real-world test confirms the theory. TrafficScript Provides a Solution TrafficScript is a feature-rich scripting language, that presents a quick and easy solution to this problem. The following response rule will inspect traffic, actioning a Location : header re-write on 301 or a 302 status code. $status = http.getResponseCode(); if (($status == 301) || ($status == 302)) {         $location = http.getResponseHeader("Location");         $new_location = string.regexsub ($location, " http:// (. ?)(/.)", " https://$1$2 ");         http.setResponseHeader("Location", $new_location); } Now, with this rule enabled, let's perform our previous test: [email protected]:# ./httpclient -m HEAD -3 <a target="_blank" href="https://www.zeus.com/internal-test">https://www.zeus.com/internal-test</a> HTTP/1.1 301 Moved Permanently Content-Length: 212 Date: Sun, 23 Jul 2006 04:10:53 GMT Connection: close Location: <a target="_blank" href="https://www.zeus.com/internal-test/">https://www.zeus.com/internal-test/</a> As you can observe, the Location header has successfully been re-written to re-direct the client to a HTTPS URI. Trafficscript in place, you can now allow ZXTM to securely and reliably interact with Microsoft Exchange, working to deliver a first-class mobile business solution for your customers. ... View more

Many customers who run ZXTM in front of a J2EE application server, like JBoss or Tomcat, would like to use the high performance SSL processing of ZXTM but still need their application to know when the connection was secured. The Apache AJP protocol can be used to achieve this<!-- A AJP 1.3 Connector on port 8009 > <Connector port="8009" address="${jboss.bind.address}" emptySessionPath="true" enableLookups="false" redirectPort="8443" protocol="AJP/1.3"/> <! A AJP 1.3 Connector on port 8010 --> Apache mod_jk   If you are connecting to JBOSS using Mod_JK with Apache or Microsoft IIS you will need to add a new worker connection for the new service. In your worker properties file for mod_jk, add a worker with the following attributes:   worker.ajp13_secure.port=8010 worker.ajp13_secure.host=localhost worker.ajp13_secure.type=ajp13   Here we created a new worker called "ajp13_secure". Now we can map requests to this worker from the Apache or IIS configuration and the applications run via this connection will be told they are secure.   The Web Server and ZXTM   You will now want to create a new virtual server. It can be a name based virtual host or you could run it on a different IP or port. You will need to be able to send the SSL traffic to this new server without causing confusion with the non secure version. This new virtual server will map J2EE apps via the ajp13_secure mod_jk worker. When you create your HTTP service with SSL Decryption enabled you will want to attach the vserver to a pool containing the service which backs onto the AJP listener you have set to be secured. In the Apache mod_jk configuration above it would map to ajp13_secure. If you are connecting with Zeus Web Server you will need to configure the Java Servlet mapping through the admin interface. If you run both secure and insecure versions of the website you will need to run two identical virtual servers. The first will take HTTP traffic and connect to the AJP listener on port 8009 (the normal service), and the second will map to the AJP listener on port 8010 (the secured version). ... View more