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