W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997


From: Scott Lawrence <lawrence@agranat.com>
Date: Thu, 04 Sep 1997 09:02:31 -0400
Message-Id: <199709041302.JAA17242@devnix.agranat.com>
To: Josh Cohen <josh@netscape.com>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4313

>>>>> "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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC