Lightweight HTTP Server Upgrades

There are a series of missing features ranked in priority order without which the product is not currently usable.
Missing Features:
1) Chunked Encoding.
2) HTTP 1.0 Support.
3) SSL Support
4) Full RESTful APIs( 4+2 HTTP APIs)
5) AoR 8 byte parameter area.
6) Keep-Alive - Config vs Code Inconsistency.
7) Locking

Chunked Encoding:
IBM DataPower Appliances amongst others rely on chunked encoding as a performance enhancement that allows the appliance to serialize XML as a stream as it parses and validates it and avoid a lot of memory buffering in the process. Consequently Chunked Encoding is required to use the zTPF HTTP Server. Chunked encoding support is only needed for inbound transactions at this time. Outbound chunking such as file transmission over a HTTP interface is not currently planned. This exists only within a single ECB lifetime an AoR_Chunked model is not necessary.

HTTP 1.0 Support:
It is not within the control of the server to dictate 1.0 vs 1.1 protocol usage, in fact with the use of HTTP proxies even if the partner configures their client to use HTTP 1.1 an intermediate layer can replace that with HTTP 1.0. There is no significant difference between 1.0 and 1.1 other than the persistence defaults given the simple server implementation. In HTTP 1.0 the default is assumed to be Connection : Close unless otherwise stated. e.g. Connection : Keep- Alive is sent in the header. In HTTP 1.1 the default is assumed to be Connection : keep-alive unless otherwise stated. This means that a relatively simple test set of AND logic tests is needed to handle the
combinations. Also you will need to track whether the client used 1.0 or 1.1 in the control table so that you can reply appropriately. HTTP 1.0 support is required to use the zTPF HTTP Server.

SSL Support:
PCI requirements and PII issues mandate SSL for all data-in-flight transmissions that contain either Credit Card or Guest's Personal Information. That means all Reservation traffic, furthermore some data deemed business critical is also encrypted on the wire (such as yield management updates).

HTTP APIs:
A RESTful service uses 4+2 APIs, the GET/PUT/POST/DELETE form the core and the HEAD and OPTIONS APIs provide support for caching and self-discovery necessary for a true RESTful implementation. It is unclear to me why the code would actively suppress support for anything other than GET and POST. From a simple SOAP based perspective POST is sufficient but the next generation is looking to support a full RESTful API and the full range of APIs is needed. Presumably the configuration file should be designed to include which APIs are supported for which URIs.

AoR 8 byte parameter area:
Currently we use the AoR parameter area to pass a control table index from ECB to ECB. The HTTP layer masks access to the AoR parm area because it is using it for the HTTP control table. Therefore a user defined parm area of (8 bytes) should be introduced for the same purpose; our control tables do more than simple HTTP handling so will need to co-exist with the HTTP layer.

Keep-Alive:
I was confused by the persistent vs non-persistent connection configuration simply because if I need to override the correct behaviour I can do so easily with code. Also the documentation states that under certain conditions the correct management of the Connection : Close parameter is a function of the application code calling the HTTP response handler; per the manual:

"Note: If a client sends a keep-alive header, it is passed to the target HTTP application. If the HTTP response includes a keep-aliver header, the connection is kept open. If not, a Connection: close header is included in the HTTP response and the connection is closed"

This now sets up a potential conflict between the HTTP server layer and the HTTP application since we have configured the server to be persistent (or non-persistent). So the presence of a redundant keep-alive in a HTTP 1.1 header which could simply be ignored now requires explicit handling by the application layer so whenever we are presented with a belt-and-braces client (and trust me there are a lot out there) the application has to code the keep-alive parameter in the response in order to achieve the configured behaviour. Code should only be used to OVERRIDE the configured behaviour e.g. to force the generation of the close on a persistent connection; not to achieve it.

Locking:
There just seems to be a lot of lockc/unlkc calls and I suspect most of the locking is unnecessary simply because the HTTP protocol ensures that there is minimal concurrency even in the face of pipelining which uses the AoR() only when the current message responds so that there are no concurrent ECBs sharing a socket. In many cases a simple CS() or the tpf_serialized_update4() could be used instead. My concern is during a rapid expansion of sockets e.g. post-IPL the number of locks could seriously impede session establishment. This code shoul