Caché Upgrade Checklists - InterSystems Documentation

Caché 2008.2 Upgrade Checklist7.2.8.5 Serve Static Files From Caché Instead Of WebServerIn earlier versions, only files of type .csp, .cls and .zen were processed in Caché by the CSP engine. All other (such asstatic) files were served by the web server. With this version, the CSP engine is capable of serving any type of file that isplaced in the CSP applications path (including static files). Among the advantages of this approach are these:• The application is simpler to administer and deploy since all the files are on the Cache server. There is no need to copystatic files to the web server machine; all files now come from the same place.• This provides the ability to remap file locations so common files may appear to be in every path when there is a singlecopy in a central location in the /csp/broker application.• Caché security rules can now be applied consistently both dynamic and static files.• The web server configuration for CSP applications to be further simplified because it is no longer necessary to createaliases in the web server configuration to represent the locations where the static files for an application reside. Thisresolves issues of contention when a single (i.e. common) web server serves two different versions of Caché, eachrequiring different versions of certain static files (for example, hyperevent broker components).To support these changes, new configuration options specified with the CSP application settings have been added:• Time to cache static files: This defaults to 1 hour if not specified. This is both the time the browser will cache this fileand also the time the CSP gateway will cache this file if this caching is turned on.• Modify the “Server Files” question to change the choices to:– No: Never server files from this application path– Always: Always server files from this application path, ignoring CSP security settings for this path for static files.This is the default for new applications; it is backward compatible with previous behavior serving files from theweb server.– Always and cached: Always server files from this application path and allow the CSP gateway to cache these filesto avoid having to request them from Caché. This is the mode most deployed application should use.– Use CSP security: If the user has permissions to view a .csp or .cls page in this application, allow them to viewtatic files, If they do not have permissions to view a .csp or .cls page then return an error code of 404 (page notfound) page. This is not cached in the gateway as only the server can decide if the user has the correct securitypermissions.Any files placed in /csp/broker will effectively appear in all directories as the server will first look to see if the file,/csp/user/file.txt, is present. If not, it will look in /csp/broker/file.txt and, if there is a file with this name there, then it willserve this file up. This will allow applications to remove hard links to /csp/broker files which makes having a single serverthat serves up applications from multiple versions of Caché possible.7.2.8.6 Password Change From Empty DetectedIn previous versions, an attempt to change passwords using the CSP password change page where the old password was“ ” did not succeed. The code acted as if no old password had been passed to it. Now, it does detect that the old passwordwas passed, was just “ ” and calls the password change code.7.2.9 XML Changes7.2.9.1 Support for Binary SOAP MessagesIf the parameter SOAPBINARY is set to 1 for a web service, then binary transmission of SOAP messages between Cachéinstances will be enabled. The web service will then support normal XML based SOAP or Caché proprietary SOAP format194 Caché Upgrade Checklists