- From: Scott Lawrence <lawrence@agranat.com>
- Date: Thu, 04 Sep 1997 09:02:31 -0400
- To: Josh Cohen <josh@netscape.com>
- Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
>>>>> "JC" == Josh Cohen <josh@netscape.com> writes:
JC> The current proposal:
JC> Leave the version as-is, but clarify that proxies MUST upragde
JC> all requests to the proxy's highest version.
JC> Issues;
JC> issue: chunked POST: this was the only concrete use where
JC> the server version is useful. Unfortunately, even 1.1 proxies/servers
JC> may not support a chunked POST. Since this is a fringe case,
Pardon me, but section 4.4 clearly states:
All HTTP/1.1 applications that receive entities MUST accept
the "chunked" transfer coding (section 3.6)
If an HTTP/1.1 proxy or server does not accept a chunked POST, it is
not compliant. No issue.
JC> issue: keep-alives in client
JC> If you have:
JC> 1.1 client -> 1.0 proxy -> 1.1 server
JC> The client will issue a 1.1 request, the proxy will downgrade it
JC> to 1.0, and the server will respond with a 1.1 response.
JC> (but 1.0 compatible, ie no chunked encoding )
JC> The proxy will then blindly forward the response ( 1.1) back to
JC> the client.
JC> ... Presumably, the client will assume 1.1 and that persistent
JC> connections are OK, but the proxy willl be closing the
JC> connections after each request.
The client must deal with arbitrary connection closes from a 1.1
server anyway; servers will implement different policies on leaving
connections open - I can't imagine AltaVista allowing a connection
to remain open long, for example, 1.1 or not.
The proposed resolution is the correct one.
--
Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Thursday, 4 September 1997 06:26:07 UTC