W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 14 Feb 2007 02:33:00 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: ietf-http-wg@w3.org
Message-Id: <1171416780.4335.33.camel@henriknordstrom.net>
ons 2007-02-14 klockan 12:04 +1300 skrev Adrien de Croy:

> I am a bit worried about the HTTP version cache though.  Do clients keep 
> a record of HTTP version
> responses of servers?

Clients:

MAY maintain a cache of servers they have seen 100 Continue responses
from. This to avoid the timer fallback when it's known the server
supports 100 Continue.

MAY maintain a HTTP Version cache of the requested server. It's unclear
if this is just the next-hop server, or the whole request path defined
by response HTTP version + Via header version trace. This to determine
if it's reasonably safe to use chunked encoding in requests as it's not
allowed otherwise.

Proxies:

SHOULD maintain a HTTP version cache of resently used next-hop servers
(both proxies and origin servers). Needed to fulfill Expect
requirements.

> In this case, must the proxy always respond with the same HTTP version 
> number that the server
> responded with?

No. Proxies MUST respond with the HTTP version they conform to.

> We breach this all the time, since we upgrade everything to HTTP/1.1 for 
> the client.

Good.

> On that note, some guidelines to web client developers on issues of 
> which connection to send what
> request down would be really useful.  For instance we see browsers 
> sending http then ftp then CONNECT
> requests down the same connection.

And what's the problem with that?

> We see them when browsing an FTP 
> server, splitting the requests
> between multiple client sessions.  It would be useful if client 
> developers were guided to keep the FTP
> requests for the same FTP server to keep coming down the same connection 
> to the proxy.

Patly agreed.

Specs focuses on minimizing the amount of connections per hop.

As indirect result proxies should if possible maintain a shared pool of
upstream connections shared by all client connections to fulfill their
part of the deal, but it's not a strict requirement.

To minimize the risk of excessive amount of connections HTTP/1.1 clients
SHOULD limit themselves to 2 connections.

But yes, some recommendation that the client should if possible prefer
reusing the same proxy connection for additional requests to the same
origin server would improve things considerably when the proxy do not
maintain a shared upstream connection pool.

Regards
Henrik

Received on Wednesday, 14 February 2007 01:33:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT