Re: pipelined client/server behaviour

On Sat, 31 Mar 2007 15:55:30 +0200, Adrian Chadd <adrian@creative.net.au>  
wrote:

>
> On Tue, Mar 27, 2007, Eric Lawrence wrote:
>> My understanding is that Opera invested in heuristic detection to  
>> determine whether pipelining is supported by an upstream proxy or  
>> server.  I'm not sure if their algorithms are public.

We are, for the most part looking for connection management problems, like  
the server repeatedly closing the connection after we try pipelining, and  
we also have a number of servers that we do not try piplining against,  
such as all Netscape servers and IIS 4 and 5.

Additionally, we are now looking for servers that just stop sending  
responses, even though there are more request in the pipeline. This  
usually happens when the server drops one or more requests from the  
pipeline. The most prominent case of this that I am currently aware of, is  
IBM's WebSphere servers, although they may have patched the problem  
recently, which ignored all request following the first HTTP request in a  
TLS Data record, this resulted in response series like 1,3,6,8 instead of  
1,2,3,4,5,6,7,8 etc.

I have also seen one ot two special cases where a server served what I  
call a "card shuffle"-response, two responses filtered into each other.  
The only way to detect this is that there will be a HTTP/0.9 like response  
following the current response on a connection known to support HTTP 1.1.

Currently, the most problematic aspect of handling sites that are not  
handling pipelining clients gracefully, is that the servers are usually  
intermediary servers that are not adding any identifying header  
information, and they are therefore invisible to the client. I suspect  
that in most cases these servers are load balancers or reverse proxies,  
although we have recently started to encounter clientside security  
software that intercepts HTTP traffic causing the same kind of problems.

> Looking at it from a basic intermediary perspective I'm tempted to  
> suggest
> "trust the client" when it comes to pipelining - if the client wishes to
> pipeling requests then pipeline requests in the same fashion over the  
> same
> connection to the origin or next-hop intermediary. The trick here is  
> trying
> to preserve the "connectionness" of a client request (much like what must
> be done for NTLM type authentication schemes to successfully pass through
> an intermediary) which might be a little different to how people see  
> things.

I have a feeling you may misunderstand how pipelining work.

Pipelining is a hop-by-hop protocol feature, not an end-to-end feature. It  
does not establish a pipelined from the client to the origin server, but  
only from the client to the connection server (which may be the origin  
server or a proxy). If the connection server supports incoming pipelined  
connections, but is not the origin server it MAY use pipelined connections  
to the next connection server in its chain, but it does not have to, and  
the proxy may send request from multiple clients over a single pipelined  
connection (unless there are other security related consideration, such as  
the connection being an authenticated connection for a given client).

A client connecting to a proxy may send pipelined requests destined for  
multiple servers over the same connection. It is up to the proxy to keep  
the sequence and connections straight, as well as which HTTP versions each  
side supports.

For Opera to use pipelining to a proxy the user must enable HTTP 1.1 for  
the proxy, and the proxy MUST respond with a HTTP 1.1 response to the  
first request from Opera (which is sent using HTTP 1.0)

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Saturday, 31 March 2007 16:51:37 UTC