Subject: p1-message-07 S 7.1.4

From: Adrien de Croy <[email-masked]>
Date: Sat, 18 Jul 2009 15:46:33 +1200

I thought it had been decided to abandon the recommendation for 2 
connections only.

But this is still in the latest draft.

"Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. A proxy SHOULD use up to 2*N connections to
another server or proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response
times and avoid congestion. "

With many sites now this behaviour is very problematic.  IE7 for instance
takes this to heart, and so doesn't work for Facebook.com through a proxy
since FB holds connections open without responding in order to signal
new personal messages.  It's easy to lock FB up with IE7 through a proxy.

More sites are doing this.

Actually IE only applies this limit it to a server (even via a proxy),
so will make more than 2 connections to a proxy.

But any client that only made 2 connections to a proxy would be quickly
dumped by users as basically unusable.  I think this para should be 
taken out.

Furthermore the requirements that the second part places on a proxy
would greatly increase the complexity of the proxy, since it would then 
have to
start multiplexing requests from different client connections over the 
same server
connections.

Cheers

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Jul 2009 10:01:45 +0200

Adrien de Croy wrote:
> ...

Yes, the was discussed before (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>), and I think 
there was agreement that something needs to change. But we never got there.

 > ...

BR, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Sat, 18 Jul 2009 20:40:07 +1200

IMHO it's not necessary even to attempt to specify such a thing in HTTP.

load capacity and ways to deal with high load are things that change 
over time with advances in hardware and network stacks.

load requirements change over time with site design.

So I'd propose simply removing any such recommendation about max 
connections.

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 19 Jul 2009 15:58:59 +0200

> dumped by users as basically unusable.  I think this para should be 

The user-agent limit is per accessed server (host component). There is
no specified limit client->proxy when the client accesses multiple sites

The limits are there to prevent unintentionall congestion and
unfairness. Both of the server resources and network.

But yes, it's frequently a problem for certain types of sites, and the
workaround of using multiple sitenames isn't exactly clean.

I would propose adding a way where the HTTP server can grant it's
clients to use more than 2 connections.

> start multiplexing requests from different client connections over the 

Why? The proxy is allowed to open two times the amount of client
connections it sees with requests for the site. In reality this means
that the proxy do not need to bother much about the limit unless it's
proactively opening connections to a server or not pooling idle
proxy<->nexthop persistent connections for reuse but randomly
distributes client requests on many workers each with their own set of
next-hop connections...

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Jul 2009 09:35:04 +1200

> no specified limit client->proxy when the client accesses multiple sites

maybe need clarification then in 7.1.4, since it currently reads:

"A single-user client SHOULD NOT maintain more than 2 connections with 
any server or proxy."

> unfairness. Both of the server resources and network.

It doesn't make any sense to me to try and address that issue in the 
protocol.

It's like we're defining a recipe for bread, and in the recipe we state 
nobody should own more than 2 loaves.

That is based on a whole series of assumptions about availability and 
capacity of resource, which even if they were valid now, will not be 
valid for all time.  Let alone the philisophical problems about whether 
HTTP should be trying to control that anyway.

Surely its up to a site to cater for the demand it gets.  Whether that's 
1 million clients each making 2 connections, or 100000 clients each 
making 20 connections.

It's up to ISPs to cater for demand they get.

Putting that should level requirement in the protocol has achieved only 
one thing:  problems for site designers coping with UAs that take it to 
heart.

Thankfully most UAs now ignore it.  The more UAs that ignore it, the 
fewer hoops site owners and authors will have to jump through to get 
around it.

> clients to use more than 2 connections.

Servers already send back an error page when they are overloaded.

Servers are free to limit connections in any way they wish.

Putting an arbitrary limit into the client can only do one thing - 
reduce user experience, something most site owners would rather not, 
which is why they set up so many different site names to get around the 
problem.

It also forces people to host on faster connections, because otherwise 
their lightly loaded site seems slow.

> connections it sees with requests for the site. 
that's not how I read the following:

"A proxy SHOULD use up to 2*N connections to another server or proxy, 
where N is the number of simultaneously active users."

I read that as 2 connections per connected client.  Since the client can 
have 2 connections each, that's only 1 connection per client 
connection.  That wouldn't require multiplexing, but is a proxy deemed 
to be a client in this case?  In which case it can only have 2 
connections to any 1 server regardless of the number of connected clients.

> In reality this means
some architectures don't lend themselves to that, esp those with 
filtering interfaces, where a filter may block execution for an 
indeterminate period.

Regards

Adrien

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2009 13:02:06 +1000

In defence of the current text, it's hardly a philosophical  
requirement; because of the way that TCP works and the way that the  
Internet was deployed circa 1996, this was a very real and serious  
concern.

I think that the limit needs to be raised at the least, and perhaps  
softened in other ways, because:
   - it assumes that pipelining is usable over the open Internet, when  
often it is not
   - congestion on Internet backbones isn't *as much* of an issue as  
it was then (AFAIK; I'll defer to others here)
   - Web pages are significantly more complex (i.e., more resources)

This last point is particularly important; in some instances you can  
see a "waterfall" of requests, two at a time, in pathological  
circumstances (e.g., accessing a Web page that references 50 images,  
all on the same host, across an ocean).

The result is that it's now common practice to deploy assets on  
multiple hosts just to avoid this limitation, and JavaScript library  
developers are starting to look at ways of bundling multiple responses  
into one, thereby tunnelling through HTTP and making the messages  
opaque. I'd say both are signs that there needs to be a change.

OTOH, I also think completely removing limitations isn't good practice  
either, because there are still networks out there where congestion is  
a problem, and having an app open multiple TCP connections (as many  
"download accelerators" do) to hog resources isn't good for the long- 
term health of the Internet either.

My personal preference would be to:
   - raise the recommended limit to something like 6 or 8 simultaneous  
connections (I believe there's been some research referenced  
previously that shows these numbers to be reasonable), and
   - explain a bit more of the motivation/tradeoffs in the text, and
   - allow servers to explicitly relax this requirement to clients for  
particular uses (perhaps in an extension; this has been discussed a  
bit on the hybi list and elsewhere), and
   - long-term, look at ways to work around this problem in a better  
way (e.g., the effort to run HTTP over SCTP).

Cheers,

On 20/07/2009, at 7:35 AM, Adrien de Croy wrote:

>>> dumped by users as basically unusable.  I think this para should  
>>> be taken out.
>>>
>>
> "A single-user client SHOULD NOT maintain more than 2 connections  
> with any server or proxy."
>
>
> It's like we're defining a recipe for bread, and in the recipe we  
> state nobody should own more than 2 loaves.
>
> That is based on a whole series of assumptions about availability  
> and capacity of resource, which even if they were valid now, will  
> not be valid for all time.  Let alone the philisophical problems  
> about whether HTTP should be trying to control that anyway.
>
> Surely its up to a site to cater for the demand it gets.  Whether  
> that's 1 million clients each making 2 connections, or 100000  
> clients each making 20 connections.
>
> Putting that should level requirement in the protocol has achieved  
> only one thing:  problems for site designers coping with UAs that  
> take it to heart.
>
> which is why they set up so many different site names to get around  
> the problem.
>
> It also forces people to host on faster connections, because  
> otherwise their lightly loaded site seems slow.
>
>>> would greatly increase the complexity of the proxy, since it would  
>>> then have to
>>> start multiplexing requests from different client connections over  
>>> the same server
>>> connections.
>>>
>>
> "A proxy SHOULD use up to 2*N connections to another server or  
> proxy, where N is the number of simultaneously active users."
>
> I read that as 2 connections per connected client.  Since the client  
> can have 2 connections each, that's only 1 connection per client  
> connection.  That wouldn't require multiplexing, but is a proxy  
> deemed to be a client in this case?  In which case it can only have  
> 2 connections to any 1 server regardless of the number of connected  
> clients.
>
>
>> In reality this means

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jul 2009 07:19:40 +0200

Connecting this thread to issue 131... 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>).

BR, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Jul 2009 18:08:16 +1200

> Internet was deployed circa 1996, this was a very real and serious 
I understand the concern, and agree at the time, with the technology and 
bandwidth available at the time, it may have been seen to be desirable.

However with the benefit of hindsight, and actually seeing what impact 
this actually had (lots of workarounds) we may come to a different 
conclusion.

As far as link bandwidth is concerned, there's not much difference 
(connection setup overhead only) between many or few connections.

So the problem places come down to certain types of intermediaries (e.g. 
NAT devices or proxies) and servers.  Many proxies already can limit the 
number of connections from a client.  Many servers also have load 
control capability.

So I think the problem is adequately covered already. 

I think the best place to manage demand / load is at the server not the 
client.  If there were to be anything in the protocol to assist this, 
that would be a better thing in my view to focus on.

There are several options for such things,

* a busy - try again later status (like SMTP 421) (actually this would 
be exceedingly useful for rate limiting connections - a try again with a 
retry-after header - maybe new status 309?).
* an advertisement for the number of connections a server will accept 
from a client
* something else

However I think these could risk over-complicating the issue for dubious 
benefit.  Are we even clear on what it is desired to limit?

Limiting number of connections may not be the issue for a server.  It 
may be something like bandwidth, or CPU or disk IO.

As it currently stands, we have an arbitrary limit on an arbitrary 
metric to solve a problem we don't know exists.  We know however it does 
create certain problems.

>   - congestion on Internet backbones isn't *as much* of an issue as it 
> was then (AFAIK; I'll defer to others here)
I've seen this many many times.  Even accessing an idle test server 
(over GB LAN) via a proxy was hugely slowed down loading many images due 
to the 2 connection limit in IE7.  It makes sites slow, whether the 
sites are overloaded or idle. 

> opaque. I'd say both are signs that there needs to be a change.
the latter is of concern.  Esp wrt caching.

> "download accelerators" do) to hog resources isn't good for the 
> long-term health of the Internet either.
even a download accelerator that opens dozens of connections isn't 
necessarily a problem.

It's kinda like market-driven economics vs socialism.

If the supplier can't keep up with demand, they have the option to 
increase supply.  Do we want to take away that option by choking the 
clients?

I guess in the end, this is all only a SHOULD level recommendation.  
Maybe also then add "clients that implement a connection limit SHOULD 
also provide a mechanism to configure the limit".

Cheers

Adrien

>> valid for all time.  Let alone the philisophical problems about 
>> whether HTTP should be trying to control that anyway.
>>
>> that's 1 million clients each making 2 connections, or 100000 clients 
>> each making 20 connections.
>>
>> deemed to be a client in this case?  In which case it can only have 2

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2009 16:09:57 +1000

AIUI, because of the way that TCP congestion control works, the impact  
is not just on the server -- it's also on the intervening network  
itself (because congestion control tries to be fair to applications on  
a per-connection basis, so someone opening lots of connections can  
crowd out others when the network starts to get congested).

As such, it isn't a simple economic relationship -- there's no natural  
incentive for clients to not hog shared network resources. This is why  
the HTTP spec imposes an artificial limit that clients have largely  
respected (at least generally).

Cheers,

On 20/07/2009, at 4:08 PM, Adrien de Croy wrote:

>> OTOH, I also think completely removing limitations isn't good  
>> practice either, because there are still networks out there where  
>> congestion is a problem, and having an app open multiple TCP  
>> connections (as many "download accelerators" do) to hog resources  
>> isn't good for the long-term health of the Internet either.
> Maybe also then add "clients that implement a connection limit  
> SHOULD also provide a mechanism to configure the limit".
>
> Cheers

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Jul 2009 18:39:24 +1200

is this for backbone and infrastructure traffic you mean?

In which case, removing spam would be a good start.  Effectively at 
least double the width of all pipes.

I would have thought slow-startup algorithms would also work against the 
advantage of opening too many connections.  Also, download managers 
generally do multiple simultaneous range requests.  The more parts you 
request, the more request/response overhead reduces your throughput, so 
there's an incentive not to go over the top there as well.

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 20 Jul 2009 09:39:23 +0200

> it was then (AFAIK; I'll defer to others here)

Backbone is much better, but there still are areas where international
connectivity (or even cross-ISP due to lack of national interconnects)
is very poor.

> opaque. I'd say both are signs that there needs to be a change.

Agreed.

> term health of the Internet either.

Download "accelerators" is my main concern as well.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 20 Jul 2009 10:10:31 +0200

> retry-after header - maybe new status 309?).

503 + Retry-After exists already for this purpose and closely related
situations.

3xx is inappropriate as it's not a redirect to a new resource.

4xx is inappropriate as the request as such (when isolated) is fine.

2xx is inappropriate as it's not a successful response.

> * an advertisement for the number of connections a server will accept 

Yes.

> * something else

Not sure anything else is needed.

> benefit.  Are we even clear on what it is desired to limit?

For normal pageloads with pipelining enabled 2 is a very reasonable
limit.

Without pipelining at least 4, maybe more.

For other applications other requrements may exists.

> sites are overloaded or idle. 

Pipelining disabled?

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 20 Jul 2009 20:49:26 +1200

> 503 + Retry-After exists already for this purpose and closely related
I thought I tried this once before and found a lack of client support 
for it.  But that's still better than 0 current support for a new one 
though.

>> sites are overloaded or idle. 

yes - via a proxy.  Due to complexity of heuristics for detecting if a 
server supports pipelining or not, and fallback processing, it's 
difficult to proxy pipelining.

We serialize all requests via WinGate, since otherwise all aspects of 
the request/response chain (including all plugin filters) need to 
support it.  We do this with TCP flow control (stop reading from the 
client socket while we process the request/response)

Regards

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 20 Jul 2009 18:59:45 +0200

mån 2009-07-20 klockan 18:39 +1200 skrev Adrien de Croy:

> advantage of opening too many connections.

Only in cases where the data requested on the connection is small. And
additionally some (not a small number) web servers are tuned to send
their data quite aggressively effectively having slowstart disabled
(when viewed from normal connection rates) until there is packet loss.

> Also, download managers 

Depends on the "chunk" size.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 21 Jul 2009 11:05:23 +1000

OK, I think we had rough consensus before, and it's been echoed here,  
that the limit needs to be raised but not completely removed.

However, I think we need to highlight this with the larger IETF to  
make sure people understand why we're raising it. I'll put it on the  
agenda for next week for discussion in Stockholm.

Cheers,

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 21 Jul 2009 13:28:34 +0100

> opaque. I'd say both are signs that there needs to be a change.

I agree with raising the connection limit a little.  It's being worked
around already, with multiple domains.

Some of us "long-polling" AJAX folks even use infinite domains, using
wildcard DNS and a per-client-instance unique id, to work around it.

Raising the connection limit will help eventually, but it won't remove
the need for those workarounds for some years, as browsers with the
limit remain in use.

It shouldn't be raised too much, as 50 connections for 50 resources on
a page is not a good thing to encourage.

However, I'd say the really worthwhile change that's long in coming is
to fix pipelining so that it can be actually deployed, and so that
it's actually efficient and reliable when used.

Usable pipelining is likely to be kinder to the network than many
connections, and it's also likely to perform better, even over fast
networks.  I'm not sure how to achieve widely-compatible pipelining,
but I have the impression it's not been seriously attempted.

HTTP over SCTP is effectively this, with the slight disadvantage that
SCTP cannot be expected to work over the whole internet for quite a
long time.  Firewalls, NATs and even operating systems still need to
acquire support for it.  (Maybe HTTP over SCTP over UDP will be more
successful at that, but very difficult for applications to implement
well).

> term health of the Internet either.

I agree.  Opening lots of connections also fails with some routes on
the internet, due to connection-tracking firewalls and NAT routers
with a limit on the number of connections they'll support.  They tend
to drop existing connections when the limit is exceeded.

> bit on the hybi list and elsewhere), and

Yes.  Right now, I use "Connection: close" for slow responses to tell
a client that it should not queue further requests on the same
connection.  It would be better to have "Connection: no-pipeline".

Without it, multiple domain workarounds are still needed.

> way (e.g., the effort to run HTTP over SCTP).

That's a good one.  But I think there's a lot of scope for improving
HTTP over TCP too, in very similar ways to the way HTTP over SCTP
works.  Particularly in the area of non-blocking multiplexed multiple
requests and responses, which SCTP does naturally and could be done in
several ways over HTTP.  Perhaps they could share some design.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 21 Jul 2009 13:50:03 +0100

> least double the width of all pipes.

Last time I checked, the big backbones kept traffic at about 5% of the
available bandwidth.  That means 95% unused.  It's for a reason.

It turns out that as you get closer to filling a pipe, the average and
peak _delays_ increase enormously and it's not possible to do things
like internet telephony and video chat...

In principle, QoS (quality of service) is a whole world of mechanisms
to permit the full bandwidth of a pipe to be used, while allocating
other factors such as latency and loss statistics to connections which
needed.

But QoS is really very difficult to make work.  It's easier and
cheaper to have big pipes with 95% spare capacity.

It's a statistical thing...

> advantage of opening too many connections.

Not really, because TCP slow-start runs independently for each
connection.  Slow-start lets you build up the data rate until you hit
the congestion window where you start getting packet loss.  If you
have many connections, they all build up into they get packet loss,
and then the total throughput rate is a similar magnitude to using a
single connection - except you out-compete other people with fewer
connections.

Two of the problems with using lots of TCP connections that I'm aware of:

  1. As already said, there's an incentive to use more connections
     than other people to get more bandwidth than other people.  As
     well as being unfair, it leads to a tragedy of the commons where the
     network performs poorly for everyone because everyone is trying to
     compete.

     That's more or less why TCP slow-start was invented.  Congestion
     collapse as a result of everyone having an incentive to
     retransmit their TCP packets too often because they outperformed
     other people.  With slow-start, they cooperate better.

  2. With lots of connections, you don't get any more throughput over
     a link which is all your own.  But you do get slightly worse
     throughput and worse average delays from the interference between
     each connection.  The delays are the main reason not to do it
     over your personal dedicated link, and why HTTP-over-SCTP (and
     it's poor approximations, pipelining/multiplxing over TCP) would
     tend to be better than lots of connections.

Finally, a reason to avoid _lots_ of connections is the same reason why
we have the TCP slow-start algorithm:

  3. Congestion collapse.  Same reason you don't let applications
     "force" TCP to retry packets at high speed.

> there's an incentive not to go over the top there as well.

Roughly speaking, people use download managers which open lots of
connections to get higher throughput with large files.

The fact that works at all is an indication that something, somewhere
is broken.  Under normal circumstances, a single TCP connection will
attain close to the maximum throughput for a route.  Needing multiple
connections to download a single file is a sign that you're working
around artificial limits, such as policy limits or broken link bonding.

For small things (text-only web pages! :-) where response time is more
important than throughput, lots of connections has the opposite
effect.

But with web pages referencing lots of resources, because of the way
HTTP does not overlap things, some more connections improves total
response time.  It still makes the response time for the main HTML
page longer though!  (But you don't see that).

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 17:29:58 +0200

> it's actually efficient and reliable when used.

pipelining works quite well to trusted/verified HTTP/1.1 servers
supporting persistent connections, provided you don't mix long haul
requests having a lot of delay in server processing with short ones
(head of line blocking issue).

the main problems with pipelining are

* Keeping the connection persistently open is a server decision, and the
client has no means of predicting if the server will accept to process
the the pipelined requests or not until it sees the response to the
previous request.

* The head of line blocking issue where the processing time (and/or
size) of one response delays all following responses, which can
introduce significant latency.

* Chunked encoding is quite fragile as message framing method. There is
quite some breakage in that area out on the net, some of which is very
hard to work around when pipelining is enabled.

Switching to SCTP as transport is a very interesting alternative for
fixing all this, but not by any means a short-term change for general
access.

> networks.

Very much so, at least as long as all requests are fast to process by
the server without too much processing latency. This has already been
proven several times more than a decade ago and one of the main reasons
why HTTP/1.1 has support for chunked encoding.

> I'm not sure how to achieve widely-compatible pipelining,

I guess Opera is the ones best positioned to answer this as they to my
best knowledge is the only major browser which has actively ventured
into the land of enabling pipelining on the masses..

> several ways over HTTP.  Perhaps they could share some design.

Probably not very feasible to do within HTTP/1.x, but maybe.. Chunked
encoding could be introduced in 1.1, so maybe something can be done in
1.2 at least for responses. But given the fact that chunked encoding is
as fragile as it is I am not too optimistic about introducing even more
complex message framing methods for HTTP/1.x over TCP..

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 21 Jul 2009 17:36:24 +0200

> around artificial limits, such as policy limits or broken link bonding.

There is also the issue of many TCP implementations having way too small
default TCP window to be able to utilize the bandwidth available today
effectively with a single connection. Fortunately the support for larger
TCP windows has been improving significantly lately.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 22 Jul 2009 10:30:29 +1200

There are many reasons in here why it's not commercially desirable to 
open many many connections.

I disagree that opening more connections = more bandwidth.  If you are 
hitting a server that allocates bandwidth on a per-connection basis then 
perhaps, but surely that's an issue with the server?  Why don't we 
instead write servers that allocate bandwidth on a client IP basis.  Or 
something else? (cookie?)  Then opening many connections would work 
against you.

There are several reasons download managers make requests in many parts e.g.

a) improved reliability.  You lose less if a single request / response 
fails for some reason
b) improved throughput to an extent if the server is allocating bandwith 
per connection, otherwise reduced throughput due to increased overhead.

Fairness is a political issue. I don't think it should be addressed in a 
technical spec.  I think there are enough real technical and commercial 
reasons to make sure one's software gets along with its neighbours.  But 
I don't believe that the metric of number of connections is necessarily 
the holy grail of what would best be restricted.

We all know what Bill Gates said 20 odd years ago about how much RAM 
anyone could ever need.  I just don't see the need to make the same 
mistake now with how many connections might be considered "too many".  
Obviously in 1996 2 connections was sufficient.  Now it's woefully 
inadequate.  So whose crystal ball do we gaze in to come up with a 
number to last the next 15 years?  I agree that say 100 connections 
feels like too many to me now, but I can't guarantee I'll feel the same 
way in 5 years, and I also believe that anyone opening 100 connections 
now would be disappointed with the results:

* not actually more throughput in many cases less.
* more problems for customers due to impact on the network / other apps
* more support calls / higher support burden / cost

Maybe we'd be better addressing some of the underlying issues another 
way?  If you've a web page with over 100 embedded small (< 2kb) images 
(e.g. http://www.nzherald.co.nz), what's the best way to get those 
images?  It's actually ridiculous when you think about it to spend 3kb 
of request/response headers to retrieve a 1kb image.

So maybe that problem is best handled in HTML specs, allow embedded 
binary elements, still with URIs so they can be cached (and 
revalidated). Even have an alternative HTML page that can be requested 
if you already downloaded the binary-embedded one.  Even if you 
downloaded the resources each time, it's still less expensive to get 
them that way than to recheck freshness with a request. 

Educating authors and site owners about caching could also go a very 
long way, but HTTP/1.1 caching is a complicated subject, which works 
against itself for that reason.  Of the people who could benefit, a 
small number may be motivated, may start reading, then put it in the 
too-hard basket in a very short time.  How many people on this planet 
really know how HTTP/1.1 caching works?  I'd suggest a very small 
fraction of those for whom the knowledge would be desirable.

The argument has also been raised about the relative merits of 
multiplexing multiple virtual connections over a single TCP connection 
vs just opening multiple TCP connections.  There's actually potentially 
less overhead in just opening multiple TCP connections.  It's a tradeoff 
between the framing you'd need in the multiplexing layer (per-block 
overhead) vs the connection setup / teardown overhead (per connection 
overhead) you'd need in the extra TCP connections.  I think if those 
connections were persistent, the multiple TCP connection approach would 
prove better.

Adrien

---

From: Patrick McManus <[email-masked]>
Date: Tue, 21 Jul 2009 20:22:14 -0400

> open many many connections.
I've always wondered why this is in the specification at all as a limit. 
As we all know, and this thread has shown, there are pros and cons to 
different approaches and different contexts change that math.

It really has very limited (if any) relevance to interop, and the 
existing "2-per" rule is widely ignored (imo both because it is 
unreasonable for many current contexts and because it really has little 
impact on interop). I would favor just dropping the requirement and 
replacing it with some non-normative language briefly discussing the 
implications of high or low levels of parallelism vs pipelining. I know 
I've ignored this requirement in the past without regret.

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 23 Jul 2009 16:02:29 +1200

Henrik Nordstrom wrote:

Problem with 503 is RFC2616 S10.5 which states this is a Server Error.
Any client that just looks at the class of the response if it's not
1xx, 2xx or 3xx will just see this as an error.

Also S10.5.3 (503 Service Unavailable) doesn't even suggest that the
client SHOULD retry after the time specified in Retry-After (if it
exists) or some other time if it doesn't.

So 503 I believe would be problematic for this case - I'll do some
testing with browsers and let you know what I find.

S 10.3 states "this class of status code indicates that further action
needs to be taken by the user agent in order to fulfil the request".

Not all 3xx codes are redirects (e.g. 304), but sure, all the rest
are.  But that's why I proposed a new 3xx code, since

a) it's not a server or client error, but indicates to the browser it
must take further action

b) none of the other 3xx codes fit, as apart from 304, they are all
redirects.

If there is widespread browser support for 503 + Retry-After, that will
work fine, but perhaps the description of 503 should be extended to
make this more likely for new implementors.

agreed

regards

Adrien

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Jul 2009 13:01:01 +0200

> 1xx, 2xx or 3xx will just see this as an error.

How is the server not yet having completed it's internal processing so
it can process the request in the expected manner not being an
(expected) server error of temporary nature?

For what it's worth the mechanism described here is unrelated to what
made the server initiate this processing. It may have been an
asyncronous POST, but may just as well have been any other action within
or outside HTTP. The case here is that the server knows it should have a
suitable representation for the response but at the time being it's
unable to provide that representation due to a temporary condition.

> exists) or some other time if it doesn't.

Well, to me that's kind of implicit that the client is expected to retry
the request after the indicated time if it's still interested by then,
this from Retry-After indicating it's a temporary issue and the name of
the header plus the talk forbidding the client from retrying before..

If any such requirement is to be added it should not be a SHOULD
requirement, at most a "MAY retry" requirement.

> testing with browsers and let you know what I find.

I think you will find that none cares about Retry-After.

> a) it's not a server or client error, but indicates to the browser it

There is no further action to be taken by the browser other than to wait
patiently while the server sorts out whatever it's currently doing and
then try the exact same request again if it is still interested in the
result by then.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Jul 2009 22:28:04 +0200

fre 2009-07-24 klockan 07:44 +1200 skrev Adrien de Croy:

> In the context of the application I was considering a "please try again 
> later" type response for, I wouldn't consider this to be an error 
> condition.  Just a server policy for rate-limiting requests.

My reasoning is that it's an error condition which prevented the server
from fulfilling the request at the moment.

But seriously, a new 4xx code with Retry-After could also be issued for
this. It's a borderline case.

> again, in the case I was considering, it's more a server policy - 
> unwilling to comply, but happy to do so in X seconds if the client retries.

And I see that as a 5xx.. server could/would not complete the request
for some reason. Nothing wrong with the request, and no special action
needed to be done by the client other than try again at a later time
when the condition has ceased.

> I've always assumed HTTP inherited its classes of error codes from SMTP, 
> but the 4xx series doesn't really fit that.  E.g SMTP uses 421 in this case.

HTTP does not use the same classes as SMTP.

In HTTP 4xx errors is permanent and the client SHOULD NOT retry the same
request (server fine, request not good) where 5xx errors quite often are
not (request probably good, but could not be processed for some
reason). 

SMTP is kind of the opposite, with 4xy being transient/temporary and 5xy
being permanent.

SMTP: 421 Service Unavailable, ....
HTTP: 503 Service Unavailable

But it's not a clear cut distinction in HTTP to be honest. 5xx is a bit
of a mixed bag and there is errors which don't fully fit either category
or which fits both..

> sure, but rate limiting requests wouldn't work if the client doesn't retry.

And clients/users won't hang around for hours if Retry-After says they
should..

> I think you're right, when I tested once before I found it was ignored.
> 
> So it's a chicken and egg situation.  Proxies/servers can't use it until 
> clients support it.  Clients don't have an incentive to use it until 
> some servers use it.

What we can do is to clarify the intended use.

> exactly - I consider retrying qualifies as some further action :)

And I don't. By actions I consider things which actually changes
something about the request.

> The server could send back a 302 with a Location header specifying the 
> original requested URI.  Some browsers will re-request (ignoring 
> Retry-After from what I've seen).  Some complain about a request loop.

No, that does not indicate the intended semantics I think. Plus will
fail badly for those not caring about Retry-After having some meaning..

> IE7 for instance will make over 3500 requests/sec to our proxy if we do 
> this in policy.  A good way to fill up HD. To rate limit in the end we 
> had to delay the response from the proxy.

Nice one.

Good thing FF warns users so these problems actually is detected
somewhere other than full logs...

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 24 Jul 2009 07:44:23 +1200

Regards

Adrien

---

From: Larry Masinter <[email-masked]>
Date: Thu, 23 Jul 2009 16:28:16 -0700

# "A single-user client SHOULD NOT maintain more than 2 connections with 
# any server or proxy."

I know why this was put in, but the circumstances which caused
the HTTP working group to add this requirement have changed
and morphed in such a way as to make this guideline not particularly
meaningful or useful.

I would be in favor of either removing this or, if it is retained,
adding more context for the circumstances where the HTTP specification
would recommend a particular implementation resource management
policy.

Larry
-- 
http://larry.masinter.net

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 24 Jul 2009 16:35:58 +0100

> introduce significant latency.

Yes, that's why I advocating multiplexing (based on chunks...), which
avoids the problem very effectively.

It still suffers from TCP head of line blocking, but that's quite
different, much shorter, does not occur on uncongested networks and
does not depend on processing time.

> hard to work around when pipelining is enabled.

Can you describe these problems?  I've not heard of any problem with
chunked response encoding, and it's very widely deployed.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 24 Jul 2009 19:10:32 +0200

> chunked response encoding, and it's very widely deployed.

Basically it makes the response splitting attack much easier, removing
any need of guessing response sizes and also completely defeats any
Content-Length the server manages to add before of the injected header
payload unless the receiver ignores specifications and verifies
Content-Length instead of ignoring it.

But as I said the damage is primarily isolated to the requested site,
and additionally the server of that site needs to be broken to exploit
it.

But me sitting on the proxy chair have a little harder time as I also
need to deal with certain "forgiving" proxies who sends shit back on me
when the server response is shit.. (not properly verifying message
boundaries wben there is excess data after the chunked encoding, or
mistakenly uses Content-Length for delimiting even when there is chunked
encoding), and in that situation the attack vector becomes serious.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 25 Jul 2009 00:24:11 +0100

> encoding), and in that situation the attack vector becomes serious.

I guess you are saying:

   1. There are real proxies which use Content-Length when they shouldn't.

   2. There are real servers which send Content-Length and chunking
      in the same response.

   3. There are real servers which produce the wrong chunk formatting?

      Do you have specific examples of wrong chunk formatting?
      Are there some well known (in implementer circles) things
      that a robust client must be prepared to accept?

-- Jamie

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 25 Jul 2009 01:33:32 +0200 (CEST)

>      that a robust client must be prepared to accept?

We seem to get funny reports on libcurl every now and then indicating this, 
but none of those cases have yet actually resulted in me having been able to 
pinpoint any specific bad software. I think it's just a result of the fact 
that there are a bunch of different implementations out there, and some of 
those softwares have (had) bugs and some of those buggy implementations are 
still existing out there.

-- 

  / daniel.haxx.se

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 25 Jul 2009 01:52:28 +0200

>    1. There are real proxies which use Content-Length when they shouldn't.

Yes. And with that being a very grey area considering that there still
is HTTP/1.0 proxies around not knowing a bit about chunked encoding.

Related to this there also is very many web servers responding with
chunked encoding in responses to HTTP/1.0 requests (MUST NOT for very
very good reasons).

Yes.

>    3. There are real servers which produce the wrong chunk formatting?

Yes, or which can be fooled into doing so.

>       that a robust client must be prepared to accept?

As implemented in our software it's actually more in the area of things
we don't accept and which causes us to reject the connection and
consider the message invalid

- Certain forms of malformed message headers
- Malformed chunk headers
- Overly large chunk sizes (bigger than we can parse 32/64 bit depending
platform & version)
- Extra data coming after the message, as this may indicate an
response-splitting attempt.

Unfortunately many implementations completely foreget to verify the data
they parse, and for example reads 4294967808 as 256 or -1, or 4294967296
as 0, or even A as 0 for that matter.

Regards
Henrik