PK21001: RECEIVING DFHSO0123 RETURN CODE 406 FROM FUNCTION 'GSK_SECURE_SOCKET_INIT' OF SSL IN TS 3.1

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You are at TS 3.1 and receiving DFHSO0123 return code 406
  from function 'gsk_secure_socket_init' of System SSL. This is
  your test system where client workstation goes directly to CICS
  Web Support. It appears that applications can be continuously
  processed, unless user pauses 30 seconds or more before pressing
  a "submit" action. You have specified SocketClose=NO.
  In the trace, see the following,
  SO 080C SOSE *EXE* - SYSTEM_SSL_ERROR GSK_RESPONSE(GSK_ERROR_IO)
  FUNCTION(SECURE_SOC_INIT) RESPONSE(EXECEPTION)
  REASON(CLIENT_ERROR)
  GSK_RETURN_CODE(196) CERTIFICATE_USERID() CIPHER_SELECTED()
  .
  Further diagnosis:
  This appears to be caused by a client error. However, there
  are some unexpected events which precede the eventual DFHSO0123.
  CICS shouldn't be scheduling the attach of a CWXN task just
  because there is some trailing 'white space/X'0D0A' in the
  socket buffer from the previous HTTP request. The fact that
  CICS close the socket prematurely is also bad (especially
  when SSL is being used).
  .
  After the closure of the socket, the next request from the
  client opens a new socket and performs another SSL handshake.
  The first data received during the handshake is 'GET /'
  instead of the initiation of a handshake. So it appears as
  though the client is sending an HTTP GET rather than an HTTPS
  GET down this new socket connection. This causes the
  DFHSO0123 message.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: DFHSO0123 with extraneous data on http  *
  *                      request.                                *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When a HTTP request is received which contains a trailing CRLF
  which is not included in the content-length header, it is
  possible for the socket connection to be closed. This is because
  a new receive is scheduled on the socket due to the extra data.
  This receive times out if no new request is received and so the
  socket connection is closed. If the socket is SSL then it
  produces error message DFHSO0123.
  Additional keywords: msgdfhso0123 so0123
  

Problem conclusion

• If CWXN detects that the data is all white space then a new
  response of white_space_only will be returned to receive
  processing. This will be recognised and error processing
  bypassed for this receive, allowing a normal async receive to
  be issued against the socket.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK15816

Modules/Macros

•    DESWBAP  DESWBDM  DESWBRQ  DESWBSR  DESWBXM
  DESWBXN  DFHWBAP  DFHWBAPF DFHWBDM  DFHWBRQS DFHWBSR  DFHWBSRA
  DFHWBSRM DFHWBSRT DFHWBXM  DFHWBXN
  

Fix information

• Fixed component name

  CICSTS 3.1 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK15816

     UP06/06/30 P F606

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.