PK58529: CICS TS 3.2 MAY RETURN 400 BAD REQUEST TO A BRIDGE REQUEST.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You may be running with an HTTP Server making a bridge
  request to CICS and this worked ok with CICS TS 3.1 but fails
  with CICS TS 3.2.  The HTTP Server issues the following
  error:
    return_code=400; HTTP_RESPONSE=200; HTErrorInfo=24;
    ERRORINFO=0
    DetailedErr. bailing out on error 24 because a plugin has
    already written the error response.
  
  The HTTP Server is using the CICS TS 3.2 level plugin file.
  When you revert back to CICS TS 3.1 and exercise the same
  transaction path the application works properly.
  
  When the error occurs at the CICS TS 3.2 level, there are no
  errors displayed in the corresponding CICS region.
  
  A CICS trace shows that the 3270 bridge transaction does
  its SEND MAP successfully and then ends but DFHWBTTA exits
  with the 400 Bad Request.  DFHWBBLI then sends the HTTP
  response 400 Bad Request.  The trace also shows DFHWBST doing
  a lot of extra processing, as is DFHWBFM:
    WB 0E01 WBFM  EXIT  - FUNCTION(URL_DECODE)
    RESPONSE(EXCEPTION) REASON(OUTPUT_BUFFER_OVERFLOW)
  This is due to the output buffer overflowing.  The only
  difference between the working CICS TS 3.1 and failing CICS
  TS 3.2 case is the document handler processing on the send
  that fails.  In the TS 3.1 case the complete document is
  x'57C4' bytes long.  In the TS 3.2 case it is x'85D6'.  The
  symbol list and the template are the same size in both
  releases.  This leaves the only difference in processing to
  be in document handler when the symbol list is added and when
  the document is retrieved by DFHWBBMS.
  
  A dump with internal trace showed where the problem is.  The
  WBOEL_HTML_BUFFER showed what all the extra data was that was
  causing the response to be larger than expected.  The problem
  actually occurs on the preceding RECEIVE MAP.  DFHWBBMS
  uses documents to process the incoming forms data and work
  out which fields have been changed by the user.  A template
  is created from all the fields in the map and the data sent
  out is added to the document.  After that is done the
  document is retrieved into a buffer so it can be compared
  with the data that has been received.  There should be a
  DELETE_DATA call issued after doing the retrieve as this data
  isn't needed anymore.  The problem we have is that the
  retrieved data didn't fit into the supplied buffer.  At CICS
  TS 3.1 that was indicated by an OK response from document
  handler and the data length being larger than the maximum.
  This was handled as a truncated buffer condition within
  DFHWBBMS and the DELETE_DATA call was done anyway.  At CICS
  TS 3.2 the document handler call now returns an exception
  response to indicate the buffer wasn't large enough.  The
  routine it is part of is now left at this point before doing
  the DELETE_DATA call.  This leaves the document with x'2E12'
  bytes in it.  When the SEND MAP is processed it works
  correctly but the data gets added after the x'2E12' bytes
  that was left there from the RECEIVE MAP.  This puts the
  length of the data from the receive over 32K and you get the
  400 Bad Request response.  The RECEIVE MAP processing code in
  CICS TS 3.2 needs to be changed so it doesn't leave any
  residual data in the document being used.
  
  Additional Symptom(s) Search Keyword(s):
  KIXREVSCB
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: 'HTTP - 400 Bad request' response may   *
  *                      be issued for a MAP that contains       *
  *                      several hidden fields when using the    *
  *                      CICS Web 3270 Bridge.                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An application using the CICS Web 3270 Bridge with DFHWBTTA
  issues a SEND MAP. The map contains several fields defined
  with the PROT and FSET attributes. A RECEIVE MAP followed by
  SEND MAP are issued for the same map which causes a 'HTTP 400
  - Bad Request' to be returned to the browser.
  This is because the allocated buffer into which the document is
  to be retrieved is not large enough to contain all of the hidden
  input fields generated from the protected FSET fields in the
  map.
  This causes the data to be truncated and an 'OVERFLOW' exception
  issued. As a result, the hidden data is not deleted from the
  Document Control record and is used when the HTTP response is
  built.
  The hidden data is inserted into the output buffer first
  followed by the map data. If this combines to give a map size
  greater than 32K the 'Bad Request' response is displayed.
  If the combined size of the map is less than 32K the hidden data
  is displayed at the browser as a symbollist before the map
  itself.
  If DFHWBTTB is used instead of DFHWBTTA the symbollist will be
  displayed at the browser before the map for map sizes above
  and below 32K in size.
  
  Additional Keywords : symbol_string
  

Problem conclusion

• DFHWBBMS has been changed so that the buffer passed to Document
  Handler on the 'retrieve_doc' call is large enough to hold the
  maximum amount of retrieved data allowed.
  

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:

  UK35919 PK72313

Modules/Macros

•    DESWBBMS DFHWBBMS
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R500 PSY UK35919

     UP08/04/30 P F804

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.