Subject: pipelined client/server behaviour

From: Adrian Chadd <[email-masked]>
Date: Wed, 28 Mar 2007 11:27:26 +0800

Hi,

I'm doing up a specification for some proxy software I'm writing and I'm stuck
trying to describe "good enough" behaviour with HTTP pipelining between
client and servers.

Pipelining seems to be one of those rarely-touched subjects, save for "its
horribly broken" but also "clients notice slower downloads when they're
behind a proxy/cache that doesn't do pipelining" (eg, Squid, and no, its
not because 'its Squid' anymore.) Its noticable for clients who are a few hundred
milliseconds away from origin servers, like Australians talking to American
web servers.

The one example of an open source web proxy/cache trying to take advantage of
HTTP pipelining is Polipo. It jumps through quite a few hoops to try and
detect whether a server is "good" or "bad" at pipelining.

About the only sane method I can see of handling pipelining in a HTTP proxy
is by pinning the server/client connections together and issuing pipelined
connections to the server just as we get them from the client. Trying
to handle pipelined requests from the client by distributing them to free
persistent connections or new server connections (a la what Squid tried to
do) seems to result in the broken behaviour everyone loathes.

So now my questions:

* Does anyone here who is involved in writing HTTP clients, servers and
  intermediaries have any light to shed on HTTP pipelining and its behaviours
  in given environments, and

* Is there any interest in trying to update the HTTP/1.1 specification to be
  clearer on how pipelined HTTP requests are to be handled and how errors
  are to be treated?

Thanks,

Adrian

---

From: Eric Lawrence <[email-masked]>
Date: Tue, 27 Mar 2007 20:49:58 -0700

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.

Trying to support pipelining is probably one of the biggest challenges I encountered in developing Fiddler.  Supporting pipelining in a user-agent is even more challenging, because you often must decide whether queueing a given request into a pipeline is likely to improve performance (vs using another connection) without knowing how large the remote file is and/or how long it will take to generate.

-Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Chadd
Sent: Tuesday, March 27, 2007 8:27 PM
To: [email-masked]
Subject: pipelined client/server behaviour

Hi,

So now my questions:

Thanks,

Adrian

---

From: Adrian Chadd <[email-masked]>
Date: Sat, 31 Mar 2007 21:55:30 +0800

> Trying to support pipelining is probably one of the biggest challenges I encountered in developing Fiddler.  Supporting pipelining in a user-agent is even more challenging, because you often must d…

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'm sure smarter intermediaries could and do get their hands dirty as they
cross the line between intermediary and client (eg, pre-fetching intermediaries)
but I'm focusing on what a normal forward or reverse HTTP proxy would/should
do.

What do you think? I think its worth trying to clarify this stuff.

Adrian

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 31 Mar 2007 18:50:21 +0200

On Sat, 31 Mar 2007 15:55:30 +0200, Adrian Chadd <[email-masked]>  
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.

> an intermediary) which might be a little different to how people see  

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: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************