PI27153: HTTP ADAPTER RESPONSE HAS CACHE HEADERS HARD CODED. PREVENTS CACHING MIDDLEWARE.

IBM Worklight Interim Fix README for 6.2.0.1

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 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