A fix is available
APAR status
Closed as new function.
Error description
If one wishes to use external HTTP cache mechanism (like Akamai) , he will need to override the default IBM Mobile First response headers (usually an adapter response) The problem is that MobileFirst Server is using hard coded (no-cache) valus in: Expires and Cache-Control headers. Therefore, caching such response is very hard or impossible .
Local fix
A new API was added to the IBM Mobile First Server API : WL.Server.addResponseHeader(name,value) It will allow to write an adapter procedure which will return new HTTP headers. For example the procedure may return some rss feed from 3rd party server. Just before exiting the procedure , the user can add WL.Server.addResponseHeader("Cache-Control","private =") (or any other HTTP header).For caching, IBM Mobile First has default values for HTTP Expires,Pragma and Cache-Control. Users are advised to use the new API and modify these (default) values to be cacheable. Users can add other custom HTTP headers which may serve other purposes. Bare in mind: if adding Cache-Control/Expires/Prgama headers value , Websphere may do post-processing on some headers. Depending on certain values. read more about it in http://www-01.ibm.com/support/knowledgecenter/api/content/SSAW57 _8.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rrun_ch ain_httpcustom.html#CookiesConfigureNoCache By default, Websphere sends responses that makes sure no cookies end up in public caches by making sure Cache-Control contains no-cache="Set-Cookie". For some reason though, this default will also add an Expires header in the past if no Expires header already exists in the response. This makes the entire response require re-validation if it is cached (this is similar to saying it's not cacheable, but not exactly the same). the flag to override such behaviour in server.xml: <httpEndpoint> ... more elements here... <httpOptions CookiesConfigureNoCache="false"/> </httpEndpoint>
Problem summary
**************************************************************** * USERS AFFECTED: * * IBM Mobile First server side developers. Mainly (HTTP) * * adapter developers. * **************************************************************** * PROBLEM DESCRIPTION: * * MobileFirst Server is using hard coded (no-cache) valus in * * Expires and Cache-Control HTTP response headers (response * * from server to mobile device). Therefore, caching such * * response is very hard or impossible . * **************************************************************** * RECOMMENDATION: * * - * **************************************************************** Bare in mind: if adding Cache-Control/Expires/Prgama headers value , Websphere may do post-processing on some headers. Depending on certain values. read more about it in http://www-01.ibm.com/support/knowledgecenter/api/content/SSAW57 _8.0.0/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rrun_ch ain_httpcustom.html#CookiesConfigureNoCache By default, Websphere sends responses that makes sure no cookies end up in public caches by making sure Cache-Control contains no-cache="Set-Cookie". For some reason though, this default will also add an Expires header in the past if no Expires header already exists in the response. This makes the entire response require re-validation if it is cached (this is similar to saying it's not cacheable, but not exactly the same). the flag to override such behaviour in server.xml: <httpEndpoint> ... more elements here... <httpOptions CookiesConfigureNoCache="false"/> </httpEndpoint>
Problem conclusion
Use the new JavaScript server API which can modify the response headers values: WL.Server.addResponseHeader(name,value) It will allow to write an adapter procedure which will add/modify HTTP headers. It can modify the cache control headers as well.
Temporary fix
Comments
APAR Information
APAR number
PI27153
Reported component name
WORKLIGHT ENTER
Reported component ID
5725I4300
Reported release
620
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2014-10-07
Closed date
2014-10-26
Last modified date
2014-10-26
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WORKLIGHT ENTER
Fixed component ID
5725I4300
Applicable component levels
R620 PSY
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSZH4A","label":"IBM Worklight"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"620","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
17 October 2021