Re: Can the response entity be transmitted before all the request entity has been read?

Jamie,

	This thread contains too many arguable statements and RFC
interpretations for me to comment on each specific issue. In short,
the result of the response entity transmitted before all the request
entity has been read is unpredictable. For what it is worth, I would
like to try to change your development direction/tactic with a general
"Keep it Simple" response/statement below.

	If you do not control all clients, including forward and
reverse _proxies_, in front of your server, then I would advise that
you assume that some of your clients will not support some RFC 2616
MUSTs and will "violate" many RFC 2616 SHOULDs. Some of your clients
will be HTTP/1.0 clients. Some will not do what you expect them to do
when receiving unusual traffic. Some proxies have adaptation agents
attached to them (content modification and virus checking are some
examples). Such agents are even more vulnerable to HTTP surprises such
as "early" responses.

	You seem to be developing an HTTP-to-application proxy rather
than a pure origin server. In that case, the most reliable strategy in
the presence of questionable traffic is often to switch to a tunnel
behavior and terminate the connection as soon as the response is sent.
It may be a design mistake to give applications control knobs that
depend on proper HTTP/1.1 support in clients. Give your applications
just the basic knobs that minimize the amount of guess work on the
proxy. If an application requires fine control of 100-Continue or
status code sending time, the application will not work reliably on
top of HTTP. Do not do anything "unusual" or border-line, and do not
expose HTTP knobs that allow your applications to involve your proxy
in such "unusual" or border-line behavior.

	More specifically, do not expect clients to receive or support
100-Continue by default. Do not expect clients to be able to recover
from receiving responses prior to them sending complete requests. Do
not spend time deciding when to close a connection in the presence of
strange traffic: close as soon as you can, usually right after sending
the final response (erroneous or otherwise).

This subjective advice is based on testing actual HTTP
implementations. YMMV.

HTH,

Alex.

-- 
Protocol performance, functionality, and reliability testing.
Tools, services, and know-how.
http://www.measurement-factory.com/

Received on Monday, 15 March 2004 13:09:44 UTC