Netscape ENTERPRISE SERVER 6.1, Manual

Page: 334 / 373

Buffered Streams
334 Netscape Enterprise Server NSAPI Programmer’s Guide • April 2002 (Draft)
Buffered Streams
Buffered streams improve the efficiency of network I/O (for example the exchange
of HTTP requests and responses) especially for dynamic content generation.
Buffered streams are implemented as transparent NSPR I/O layers, which means
even existing NSAPI modules can use them without any change.
The buffered streams layer adds following features to the Netscape Enterprise
Server:
• Enhanced keep-alive support: When the response is smaller than the buffer
size, the buffering layer generates the
content-length
header so that client
can detect the end of the response and re-use the connection for subsequent
requests.
• Response length determination: If the buffering layer cannot determine the
length of the response, it uses HTTP 1.1 chunked encoding instead of the
content-length
header to convey the delineation information. If the client
only understands HTTP 1.0, the server must close the connection to indicate
the end of the response.
• Deferred header writing: Response headers are written out as late as possible
to give the servlets a chance to generate their own headers (for example, the
session management header
set-cookie
).
• Ability to understand request entity bodies with chunked encoding: Though
popular clients do not use chunked encoding for sending
POST
request data,
this feature is mandatory for HTTP 1.1 compliance.
The improved connection handling and response length header generation
provided by buffered streams also addresses the HTTP 1.1 protocol compliance
issues where absence of the response length headers is regarded as a category 1
failure. In previous Enterprise Server versions it was the responsibility of the
dynamic content generation programs to send the length headers. If a CGI script
did not generate the
content-length
header, the server had to close the
connection to indicate the end of the response, breaking the keep-alive mechanism.
However, it is often very inconvenient to keep track of response length in CGI
scripts or servlets, and as an application platform provider, the web server is
expected to handle such low-level protocol issues.