PH48206: PROVIDE OPTION TO SEND 408 RESPONSE INSTEAD OF CLOSING KEEPALIVE CONNECTION

APAR status

• Closed as program error.

Error description

• Provide option to send 408 response instead of closing keepalive
  connection
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  All users of IBM HTTP Server                *
  ****************************************************************
  * PROBLEM DESCRIPTION: Browsers that encounter an HTTP         *
  *                      keepalive do not retry HTTP POST        *
  *                      requests.                               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Browsers such as chrome may try to reuse a connection far longer
  than IHS is willing to keep it alive.   By default, chrome uses
  a 5 minute timer and does not parse the servers Keep-Alive
  response header.
  When IHS closes a connection, and the browser reuses it within
  the approximate round-trip-time (latency) between the two, the
  browser may misinterpret this closure as being an error
  encountered during the handling of the latest request.
  If the request was an HTTP POST, the browser will not retry the
  request automatically.  If the request was driven by application
  javascript, it can technically be retried, but the application
  does not have enough information to be sure the server didn't
  process the first POST -- this logic would have to be
  implemented using something like transaction IDs.
  This APAR provides a mechanism to allow the server to respond
  with an HTTP 408 error when the keepalive timeout occurs, which
  chrome-based browsers interpret as meaning the POST that raced
  with the closure to be retryable.
  This new behavior is controlled with the KeepAliveTimeoutSend408
  directive, defaulting to OFF.
  On Linux and z/OS, it is currently considered more advisable to
  set a > 5 minute KeepAliveTimeout.  On other operating systems,
  a large KeepAliveTimeout may cause higher demand for IHS
  threads.
  

Problem conclusion

• The code was updated to allow opt-in to sending an HTTP 408
  error on every HTTP keepalive closure, which should help chrome-
  based browsers retry POSTS safely.  However, for now a
  KeepAliveTimeout of more than 300 seconds is a preferrable
  solution.
  
  The fix for this APAR is targeted for inclusion in IBM HTTP
  Server fix pack 9.0.5.14. For more information, see 'Recommended
  Updates for WebSphere Application Server':
  https://www.ibm.com/support/pages/node/715553
  

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

  IBM HTTP SERVER

• Fixed component ID

  5724J0801

Applicable component levels