Skip to Main Content
Cloud Platform

This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace WebSphere Liberty
Created by Guest
Created on Jul 19, 2023

Add new option to IBM WAS and Liberty to allow customers to configure WAS/Liberty to not close HTTP connections when WAS/Liberty are sending back response where the HTTP response code is greater than 399

We are making heavy use of IBM z/OS Connect and IBM z/OSMF.  We have found that when a request fails in zCEE and zOSMF, the underlying Liberty product sends back a HTTP response code greater than 399 and closes the HTTP connection from the client.


Initially IBM Liberty support advised us that IBM WAS/Liberty did this because that was what the relevant RFC specification said should be done.


Recent advice from IBM is that this is incorrect, in that the RFC do not say this, and it was a decision made by IBM WAS/Liberty development when these products were developed to behave in this way.


The impact of this behaviour to us, is that we set up our environment to use HTTP persistent connections from our clients to zCEE and zOSMF.  Some requests fail for whatever reason, zCEE and zOSMF connections are closed and since these connections are over SSL/TLS, the client needs to create new SSL/TLS connections, which means there is overhead in recreating these connections.


What we are requesting is that a new option be added to IBM WAS and Liberty, that would let us and any customer set this new setting to tell WAS/Liberty to NOT close the HTTP connections under any circumstances, meaning that IBM WAS/Liberty would not close the HTTP connection if the HTTP response code is greater than 399. 


Perhaps if possible, the option could be set up to allow customers to specify a list of HTTP response codes, such that if the HTTP response code being sent back was in the list, then the connection is left open, otherwise if the response code is not in the list, the connection is closed.

Idea priority Low
  • Guest
    Aug 25, 2023

    Thank you for the suggestion. As detailed in prior comments the requested solution would not be implementable without violating the HTTP 1.1 specification and the alternative requested would be similarly unsafe. While a broad change as requested would be unsafe there are response codes above 4xx that maybe safe to hold the connection open such as 404, so we created to track that idea with the upstream Open Liberty project. Since that idea is significantly different from what is requested we have decided to mark this one as not being done rather than in future closing it with a different behaviour. If you would like to discuss this decision further, please contact Graham Charters <>.

  • Guest
    Jul 19, 2023

    There isn't anything in RFC 9112 (the specification for HTTP 1.1) that says a response greater than 399 must close the connection. Instead the reason Liberty does this is due to Section 9.3 which covers the concept of persistent connections and it says the following:

    In order to remain persistent, all messages on a connection need to have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 6. A server MUST read the entire request message body or close the connection after sending its response; otherwise, the remaining data on a persistent connection would be misinterpreted as the next request.

    ome of the response codes greater than 399 indicate error conditions that mean it is either impossible or practically impossible for the server to honor this requirement. For example a request that does not set a message length could not be fully read by the server and if treated this way could result in an http smuggling vulnerability. This is highlighted in a number of other places in the RFC that explicitly call out that a 400 (bad request) response should result in the connection being closed, for example the last paragraph of section 2.2 states:

    When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server SHOULD respond with a 400 (Bad Request) response and close the connection.

    While this doesn't cover all error codes explicitly above 400 there are other 4xx response codes that do mean a server couldn't meet the requirements of persistent connections. Given their nature it is also unlikely that a guarantee cannot be offered for 5xx responses either. As such it would not be safe to provide a general property as requested since it would violate the persistent connections part of the HTTP 1.1 specification. The backup of allowing specific response codes to not close the connection would also likewise be unsafe since we cannot guarantee the server would correctly implement the persistent connection requirements in those cases.

  • Guest
    Jul 19, 2023

    Also, this is implied in the description, but this behavior only applies to persistent connections.

  • Guest
    Jul 19, 2023

    This is not quite accurate. This only applies to HTTP < 2.0 and this occurs for codes 400, 402-417, or 500-505: