Subject: HTTP2 Expression of Interest : Squid

From: Amos Jeffries <[email-masked]>
Date: Sun, 15 Jul 2012 22:02:10 +1200

As the current Squid proxy maintainer this is my expression of interest 
in HTTP/2.0. It is made as an individual submission with a mind for the 
Squid Project and user community needs but due to the collaborative 
nature of the Squid Project does not represent the Project as a whole.

The Squid Project implements a general-use HTTP proxy with capabilities 
including but not limited to; caching, content adaptation, content 
generation and assembly, content filtering, access control, HTTP 
routing, HTTP and HTTPS interception, HTTP traffic quality of service 
flow controls, and traffic optimization.

The development of improved HTTP protocol in all forms is of high 
interest to the Squid Project. Fast and efficient proxy operations are 
of paramount interest for the Squid user community.

HTTP/1.1 issues

The Squid Project developers are aware of numerous issues surrounding 
syntax parsing and processing which complex handling limits the 
throughput capacity of proxy installations. These syntax parsing 
inefficiencies are directly impacting on the user community goal of high 
performance.

The Squid Project community has often expressed feedback complaints 
which after investigation turn out to be based on HTTP connection 
capabilities, largely inherited from HTTP/1.0 default connections-close 
behaviours but which also remain within HTTP/1.1 due to dynamic content 
and limitations with pipelining failure recovery. Improved connection 
multiplexing and pipelining is seen as a desirable behaviour for better 
performance by many within the Squid community.

HTTP/1 contains a few signalling issues which have on occasion led to 
inefficient designs being implemented to avoid problems. The 1XX status 
feature of HTTP/1 goes some way towards this. However a more efficient 
signalling feature is needed to raise the overall efficiency of HTTP.

HTTP/1 is implicitly limited to TCP-like stream transports. There have 
been user community proposals for extension to transmit HTTP over other 
protocols. These are echoed by a number of RFC proposals for alternative 
protocols to transfer the same resources over other datagram and 
security-oriented transfer protocols. The Squid user community includes 
groups with particular interests in such additional protocol underlays 
for HTTP and seeing any future deployments more flexible than the 
current infrastructure.

HTTP/2 interest

The Squid proxy implementation is driven by community contributions, 
with guidance from a group of core developers maintaining Project focus 
and consistency. As such I cannot speak for certain about whether Squid 
Project will (or not) implement any particular proposal in the future.

draft-mbelshe-httpbis-spdy-00
-----------------------------

The SPDY proposal appears to offer an alternative to HTTPS, but is 
tightly tied to TCP and TLS infrastructure. As such it cannot meet the 
transport portability and message transparency requirements several 
groups within the Squid user community have as mandatory features for 
both operational and legal reasons. Nor can it efficiently support the 
interception and transformation needs of a large portion of the community.

There have been community requests for implementation of the SPDY 
protocol within Squid. However as yet none of the community have been 
willing to produce an implementation. Also, due to lack of 
implementation for SPDY connection to proxies from Browsers the public 
implementation focus of SPDY within Squid community has been limited to 
discussions of whether SPDY could be intercepted and translated back 
into HTTP/1, and for implementing a SPDY gateway with any efficiency.

There are also a number of semantic feature extensions above and beyond 
HTTP/1 included in this specification. This may or may not be an issue 
for implementation, but it seems early to spring new semantics

My view is that SPDY layering should be separated and the non-HTTP layer 
considered as an alternative transport for HTTP similar to TCP, UDP, 
STCP, CoAP and HTCP which all seek to relay HTTP messages. Only the HTTP 
specific syntax and framing improvements should be considered by the WG 
as input to HTTP/2 specifications.

draft-montenegro-httpbis-speed-mobility-02
------------------------------------------

This proposal lacks a measure of support for HTTP/1 features. A gateway 
definition for translation of HTTP/1 features into the mobility frames 
is sadly lacking.

Since this proposal uses WebSocket framing; there have been no comments 
or requests from the Squid user community or developers towards 
implementing WebSockets in Squid. The developer projects to my knowledge 
are limited to intercepting WebSockets and translating as much as 
possible into HTTP/1 traffic.

My view is that the introductory sections of this draft should be 
considered as important requirements input to the WG designs.

draft-tarreau-httpbis-network-friendly-00
-----------------------------------------

This proposal has been designed with the SPDY improvements and many of 
the problems identified by the Squid community and developers in mind. 
It contains mandatory functionality which are seen by the Squid user 
community as beneficial for high-performance proxying; multiplexing and 
pipelining, flow control (implied, not stated specifically), and 
efficient HTTP-specific header compression. While leaving optional all 
features which are beneficial only to specific groups within the Squid 
user community and HTTP environment as a whole; security, 
authentication, data integrity, push/pull, and sessions.

As co-author of this proposal I have been working on an implementation 
for use within the Squid code and use by other projects.

My view on this is naturally biased, that the WG should take this draft 
as an outline on which to adapt the framing specifics and integrate the 
HTTP/2 requirements.

Overall Perspecitive:

I look forward to working with the HTTPbis working group on combining 
the designs from all these proposals into a final HTTP/2 specification. 
As specified currently none of the proposals are suitable for large 
scale implementation, but all have some small measure of support from 
within the user community.

Amos Jeffries
Squid Project

---

From: tom <[email-masked]>
Date: Sun, 15 Jul 2012 18:19:42 +0800

Support on "My view is that SPDY layering should be separated and the
non-HTTP layer considered as an alternative transport for HTTP similar to
TCP, UDP, STCP, CoAP and HTCP which all seek to relay HTTP messages. Only
the HTTP specific syntax and framing improvements should be considered by
the WG as input to HTTP/2 specifications."

BTW, we have been running HTTP over UDP (scheme as HTTP) successfully.

Best regards
  Tom

On Sun, Jul 15, 2012 at 6:02 PM, Amos Jeffries <[email-masked]> wrote:

> As the current Squid proxy maintainer this is my expression of interest in
> HTTP/2.0. It is made as an individual submission with a mind for the Squid
> Project and user community needs but due to the collaborative nature of the
> Squid Project does not represent the Project as a whole.
>
>
> generation and assembly, content filtering, access control, HTTP routing,
> HTTP and HTTPS interception, HTTP traffic quality of service flow controls,
> and traffic optimization.
>
> The development of improved HTTP protocol in all forms is of high interest
> to the Squid Project. Fast and efficient proxy operations are of paramount
> interest for the Squid user community.
>
>
> HTTP/1.1 issues
>
> syntax parsing and processing which complex handling limits the throughput
> capacity of proxy installations. These syntax parsing inefficiencies are
> directly impacting on the user community goal of high performance.
>
> The Squid Project community has often expressed feedback complaints which
> after investigation turn out to be based on HTTP connection capabilities,
> largely inherited from HTTP/1.0 default connections-close behaviours but
> which also remain within HTTP/1.1 due to dynamic content and limitations
> with pipelining failure recovery. Improved connection multiplexing and
> pipelining is seen as a desirable behaviour for better performance by many
> within the Squid community.
>
> groups with particular interests in such additional protocol underlays for
> HTTP and seeing any future deployments more flexible than the current
> infrastructure.
>
>
> HTTP/2 interest
>
> The Squid proxy implementation is driven by community contributions, with
> guidance from a group of core developers maintaining Project focus and
> consistency. As such I cannot speak for certain about whether Squid Project
> will (or not) implement any particular proposal in the future.
>
>
> The SPDY proposal appears to offer an alternative to HTTPS, but is tightly
> tied to TCP and TLS infrastructure. As such it cannot meet the transport
> portability and message transparency requirements several groups within the
> Squid user community have as mandatory features for both operational and
> legal reasons. Nor can it efficiently support the interception and
> transformation needs of a large portion of the community.
>
> There have been community requests for implementation of the SPDY protocol
> within Squid. However as yet none of the community have been willing to
> produce an implementation. Also, due to lack of implementation for SPDY
> connection to proxies from Browsers the public implementation focus of SPDY
> within Squid community has been limited to discussions of whether SPDY
> could be intercepted and translated back into HTTP/1, and for implementing
> a SPDY gateway with any efficiency.
>
> HTTP/1 included in this specification. This may or may not be an issue for
> implementation, but it seems early to spring new semantics
>
> considered as an alternative transport for HTTP similar to TCP, UDP, STCP,
> CoAP and HTCP which all seek to relay HTTP messages. Only the HTTP specific
> syntax and framing improvements should be considered by the WG as input to
> HTTP/2 specifications.
>
>
> draft-montenegro-httpbis-**speed-mobility-02
> ------------------------------**------------
>
> definition for translation of HTTP/1 features into the mobility frames is
> sadly lacking.
>
> Since this proposal uses WebSocket framing; there have been no comments or
> requests from the Squid user community or developers towards implementing
> WebSockets in Squid. The developer projects to my knowledge are limited to
> intercepting WebSockets and translating as much as possible into HTTP/1
> traffic.
>
> draft-tarreau-httpbis-network-**friendly-00
> ------------------------------**-----------
>
> This proposal has been designed with the SPDY improvements and many of the
> problems identified by the Squid community and developers in mind. It
> contains mandatory functionality which are seen by the Squid user community
> as beneficial for high-performance proxying; multiplexing and pipelining,
> flow control (implied, not stated specifically), and efficient
> HTTP-specific header compression. While leaving optional all features which
> are beneficial only to specific groups within the Squid user community and
> HTTP environment as a whole; security, authentication, data integrity,
> push/pull, and sessions.
>
> As co-author of this proposal I have been working on an implementation for
> use within the Squid code and use by other projects.
>
> My view on this is naturally biased, that the WG should take this draft as
> an outline on which to adapt the framing specifics and integrate the HTTP/2
> requirements.
>
>
> Overall Perspecitive:
>
> I look forward to working with the HTTPbis working group on combining the
> designs from all these proposals into a final HTTP/2 specification. As
> specified currently none of the proposals are suitable for large scale
> implementation, but all have some small measure of support from within the
> user community.
>
>
>
> Amos Jeffries
> Squid Project
>
>
>

---

From: tom <[email-masked]>
Date: Sun, 15 Jul 2012 18:21:16 +0800

BTW, we have been running HTTP over UDP (scheme as HTTPP) successfully.

Best regards
  Tom

On Sun, Jul 15, 2012 at 6:19 PM, tom <[email-masked]> wrote:

>
> On Sun, Jul 15, 2012 at 6:02 PM, Amos Jeffries <[email-masked]>wrote:
>
>> Squid Project and user community needs but due to the collaborative nature
>> of the Squid Project does not represent the Project as a whole.
>>
>>
>> interest to the Squid Project. Fast and efficient proxy operations are of
>> paramount interest for the Squid user community.
>>
>>
>> HTTP/1.1 issues
>>
>> transport portability and message transparency requirements several groups
>> within the Squid user community have as mandatory features for both
>> operational and legal reasons. Nor can it efficiently support the
>> willing to produce an implementation. Also, due to lack of implementation
>> for SPDY connection to proxies from Browsers the public implementation
>> focus of SPDY within Squid community has been limited to discussions of
>> whether SPDY could be intercepted and translated back into HTTP/1, and for
>> implementing a SPDY gateway with any efficiency.
>>
>> are limited to intercepting WebSockets and translating as much as possible
>> into HTTP/1 traffic.
>>
>> the problems identified by the Squid community and developers in mind. It

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jul 2012 12:29:54 +0200

On 2012-07-15 12:19, tom wrote:
> non-HTTP layer considered as an alternative transport for HTTP similar
> to TCP, UDP, STCP, CoAP and HTCP which all seek to relay HTTP messages.
> Only the HTTP specific syntax and framing improvements should be
> considered by the WG as input to HTTP/2 specifications."
 > ...

+1

> ...

Out of curiosity: who is "we"?

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Jul 2012 10:05:31 -0700

Note that, if ever one will wish to implement server push or anything
similar, there are ordering requirements that must be placed on at least
the content delivery of the requested resource and its associated metadata.

It is all cost/benefit tradeoffs, all the way down. :)

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 15 Jul 2012 19:27:51 +0200

Hi Roberto,

> the content delivery of the requested resource and its associated metadata.

Doug's EOI made me think again about server push. You may remember, we
discussed the subject for countless hours when we met, with the problem
basically being that when a client fetches a page, it also wants the
objects in that page. Doug seems to need server push for instant delivery
to the client of fresh new contents, which is different. And if we look
at how the web is currently changing, we have more and more application
code running on the browser (sometimes a smartphone) which parses contents
delivered by the server. I suspect that once we have MUX in WebSocket, this
new model will become even more prevalent.

All this to say that maybe in the near future, the real need for server
push will be for raw data processed by the application and not that much
about page objects. I may be wrong, but this is probably something to
think about, since in the end it will tell us whether we have to break
the request/response model or not, which has a huge impact on content
filtering BTW.

> It is all cost/benefit tradeoffs, all the way down. :)

Exactly :-)

Cheers,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 16 Jul 2012 10:31:34 +1200

> It is all cost/benefit tradeoffs, all the way down. :)

Aye, we left this out of the network-friendly draft -00 due to being 
undecided and push discussions being up in the air.

But after reading the other proposals (WebSockets RFC and Montenegro 
draft specifically) I have come up with a nice way within the 
network-friendly framing syntax to perform user sessions and server-push 
*without* baking either of those features into the transport frame 
syntax directly. This meets the gateway to HTTP/1 requirements fror 
immediate implementation rollouts and allows those features to be easily 
added as extensions once we have more migration away from HTTP/1.
  In a similar way to how we have the messaging design and layout in the 
current HTTPbis drafts, with Ranges, Auth and Caching as separate 
followup drafts/sections.

AYJ

>
> -=R
> On Jul 15, 2012 3:31 AM, "Julian Reschke" wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Jul 2012 15:51:33 -0700

Server push is a terribly overloaded term.

In my case I'm referring to resources that would have been inlined into the
page. To avoid races, one must advertise that one will push that resource,
and since many pages are generated dynamically, this must be possible to
advertise after the headers have been sent.

The other case is full-duplex bidirectional streams, which is the domain of
the Websocket API, IMHO.

-=R

---

From: Mike Belshe <[email-masked]>
Date: Sun, 15 Jul 2012 16:26:13 -0700

> new model will become even more prevalent.

Websockets is at the wrong layer and does not do content delivery - e.g. a
websocket response will never ever land you in the client's cache.

> the request/response model or not, which has a huge impact on content

Server push doesn't break the request response model.  You issue a request,
you get a response.  You can't get responses without requests.

As for impact on content filtering, I think you're quite mistaken.  Using
server push allows the content to look like content and makes it much
*easier* to do filtering.  If we do as you proposed above (and move it to
websockets) then it becomes opaque data and much harder to apply common
filtering rules.

Mike

---

From: Jonathan Ballard <[email-masked]>
Date: Sun, 15 Jul 2012 17:22:15 -0700

In an offline study, without any connection to IETF, I (we) found
server-push too costly in HTTP-SMS gateways, which includes upgrades to MMS
That is easily exploited, even with websockets, so that/this becomes one
use-case for implementation of HTTP status 402. Of course, it polls, so
that is the request, and then the server-push happens. We have shown more
elaborate actions in another WG.

While offline, there is no way to resolve the issue except to disable
polls, so maybe that should be the default for 402 from causes like the
use-case.

Tested.

On Sun, Jul 15, 2012 at 4:26 PM, Mike Belshe <[email-masked]> wrote:

> Server push doesn't break the request response model.  You issue a
> request, you get a response.  You can't get responses without requests.
>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 16 Jul 2012 07:55:14 +0200

Hi Mike,

> websocket response will never ever land you in the client's cache.

Indeed, this is a good point. I was mostly thinking about dynamic contents
in fact.

> you get a response.  You can't get responses without requests.

OK but some data may end up in the client's cache without having been
requested by him. I don't think it has a high technical impact, but it
may rather be a legal one in some cases. In fact it's a delicate question.

> websockets) then it becomes opaque data and much harder to apply common

Note that I'm not advocating the use of WS to retrieve objects, I was just
observing that more and more contents are delivered as data to applications,
so I'm not saying that I'd prefer to filter them in one form or another.
Concerning filtering, I think that what embarrasses me a bit with server
push is the difficulty of applying URL-based filtering. But maybe this is
just a problems which needs to be carefully addressed so that it is not a
problem at all.

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Sun, 15 Jul 2012 23:06:25 -0700

Hi Willy,

On Sun, Jul 15, 2012 at 10:55 PM, Willy Tarreau <[email-masked]> wrote:

> request,

Let's not pretend that browsers behave differently than they do.  With HTTP
today,  browsers download subresources - whether you use IE or Chrome or
Opera or Safari.  All server push does is allow the server to optionally
send the secondary resources without waiting for a second request from the
client.  Servers that think this is illegal don't have to do it.  Clients
that don't want it (these don't exist!) can cancel them.  Sending resources
the browser won't use are no-ops and won't impact anything (except make
your web page load slower, so don't do it).

> just a problems which needs to be carefully addressed so that it is not a

URL based filters will work great with server push, as every pushed
response has a unique URL.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 16 Jul 2012 08:16:02 +0200

> your web page load slower, so don't do it).

You forgot the proxy between the client and the server :-)
Typically the one which at my company and my customers prevents me from
accessing a number of websites based on URL classification.

> response has a unique URL.

OK. But what if the server pretends this URL being anything else (including
random) ? Well anyway this is too early to discuss this now. From a technical
point of view I'm convinced about the efficiency of server push, my concerns
are only about efficient deployments, so I think this will be discussed to
great extents later. Let's not pollute the EOI threads with this.

Cheers,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Sun, 15 Jul 2012 23:25:27 -0700

> accessing a number of websites based on URL classification.

No, I didn't forget this :-)  The proxy has full visibility to the server
push urls and can filter them too.  Also, server push requires that clients
and servers abide by the same-origin policy.  So you can't push resources
from random domains.

> random) ?

This is possible with or without server push - proxies can do this today.
 This is why we need to make sure proxies can't tamper content.

> Well anyway this is too early to discuss this now. From a technical

ok

mike

---

From: James M Snell <[email-masked]>
Date: Sun, 15 Jul 2012 23:33:40 -0700

On Sun, Jul 15, 2012 at 11:06 PM, Mike Belshe <[email-masked]> wrote:

> [snip]
> Let's not pretend that browsers behave differently than they do.  With
> HTTP today,  browsers download subresources - whether you use IE or Chrome
> or Opera or Safari.  All server push does is allow the server to optionally
One possibility to throw in here would be a simple requirement that the
server has to ask the client before it pushes... a reverse 100-Continue if
you will... require the server to tell the client what content it is trying
to push and give the client the opportunity to say No.... intervening
proxies, such as a corporate firewall, would be capable of answering on the
users behalf.

- James

---

From: Mike Belshe <[email-masked]>
Date: Sun, 15 Jul 2012 23:35:35 -0700

> proxies, such as a corporate firewall, would be capable of answering on the

If you have a proxy, the proxy receives the pushes (not the client), so the
proxy can do whatever it would do in the non push case.

mike

---

From: Roberto Peon <[email-masked]>
Date: Sun, 15 Jul 2012 23:36:57 -0700

That would be pretty pointless-- at that point the browser should just send
the data. The model in SPDY is push and let cancel.
Server push is just better inlining.

Let's discuss this in  a separate thread...

-=R

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 16 Jul 2012 11:42:13 +0000

Hi Mike

there must be some sort of context associated between the client and 
the server for the push, otherwise what is the server pushing at?

This context would be established first by some request?  E.g. 

Shouldn't the client request server push, and transmit a context that 
the server can use to associate the many responses.

That then also allows an intermediary to track what is going on (e.g. 
demux on a shared connection), and allows the client to decide whether 
server push happens or not.

Adrien

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "James M Snell" <[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>;"Roberto Peon" 
<[email-masked]>;"Julian Reschke" <[email-masked]>;"Amos 
Jeffries" <[email-masked]>;"HTTP Working Group" 
<[email-masked]>;"tom" <[email-masked]>
Sent: 16/07/2012 6:35:35 p.m.
Subject: Re: HTTP2 Expression of Interest : Squid
>   may rather be a legal one in some cases. In fact it's a delicate 
   
   Let's not pretend that browsers behave differently than they do.  
   With HTTP today,  browsers download subresources - whether you use 
   IE or Chrome or Opera or Safari.  All server push does is allow the 
   server to optionally send the secondary resources without waiting 
   for a second request from the client.  Servers that think this is 
   illegal don't have to do it.  Clients that don't want it (these 
   don't exist!) can cancel them.  Sending resources the browser won't 
   use are no-ops and won't impact anything (except make your web page 
   load slower, so don't do it).

  One possibility to throw in here would be a simple requirement that 
  the server has to ask the client before it pushes... a reverse 
  100-Continue if you will... require the server to tell the client 
  what content it is trying to push and give the client the opportunity 
  to say No.... intervening proxies, such as a corporate firewall, 
  would be capable of answering on the users behalf. 
 
 If you have a proxy, the proxy receives the pushes (not the client), 
 so the proxy can do whatever it would do in the non push case.  
 
 mike

  - James

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Jul 2012 08:31:28 -0400

> may rather be a legal one in some cases. In fact it's a delicate question.

I hesitate to comment, because I've only got a partial push
implementation for firefox (and that's on hold right now just due to
other priorities) - but the approach I've taken helps I think. Pushed
resources are kept in a partitioned cache that is scoped to just the 1
"associated-to" resource that triggered the push. When the associated-to
resource goes away so does the pushed cache (and is never persisted to
disk). Documents are promoted out of this micro cache into the real
profile-wide cache when a request is made for them as a sub-resource of
the associated-to resource and they "hit" in the micro cache.

maybe that helps.

-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Jul 2012 09:50:09 -0400

On Sun, 2012-07-15 at 23:36 -0700, Roberto Peon wrote:
> That would be pretty pointless-- at that point the browser should just
> send the data. The model in SPDY is push and let cancel.

fwiw .. The middle ground is use of flow control to limit the amount of
data that can be pushed.. that way small pushes that are rtt bound still
get performance benefits and bigger pushes have a limited amount of
bandwidth they can consume before being validated by a url
filter. (and of course from a browser pov the leading bytes of a
response are more interesting than the trailing bytes, so even this
partial push before the window-update rtt after going through the filter
is quite valuable).

I intend to experiment with that approach.

>         
>         
>         One possibility to throw in here would be a simple requirement
>         that the server has to ask the client before it pushes... a
>         reverse 100-Continue if you will... require the server to tell
>         the client what content it is trying to push and give the
>         client the opportunity to say No.... intervening proxies, such
>         as a corporate firewall, would be capable of answering on the
>         users behalf. 
>         
>         
>         - James

---

From: Mike Belshe <[email-masked]>
Date: Mon, 16 Jul 2012 07:19:36 -0700

On Mon, Jul 16, 2012 at 4:42 AM, Adrien de Croy <[email-masked]> wrote:

>
> Hi Mike
>
> there must be some sort of context associated between the client and the
> server for the push, otherwise what is the server pushing at?
>

Correct; in the spdy protocol this is the associated stream id.  Further,
the scope and lifetime of the associated stream id is carefully crafted so
that they are finite - you can't keep pushing additional associated
resources after you've finished the primary resource.

> This context would be established first by some request?  E.g.
Shouldn't the client request server push, and transmit a context that the
> server can use to associate the many responses.
>
>

Yes, it does.  When I fetch http://www.microsoft.com/ I'm setting up the
context, and www.microsoft.com may optionally decide to associate
'style.css' into that context.

> server push happens or not.

I strongly advise against client-side push enabling.  We've seen that movie
before, such as when the client decides whether or not the server can
compress or when the client decides whether or not the server can use
pipelining.  Making it a client decision kills the feature entirely.  We
need to either support push or not support it.  But seriously, who are
these clients which will reject the pushes?  You can't push random data.
 You can only push in-domain data.  If the browser doesn't need it, you
only hurt yourself.  Seriously, why would any browser block the push?

Mike

> Cc: "Willy Tarreau" <[email-masked]>;"Roberto Peon" <[email-masked]>;"Julian
> Reschke" <[email-masked]>;"Amos Jeffries" <[email-masked]>;"HTTP
> Working Group" <[email-masked]>;"tom" <[email-masked]>
> On Sun, Jul 15, 2012 at 11:33 PM, James M Snell < <[email-masked]>
> [email-masked]> wrote:
>
>>
>>
>> On Sun, Jul 15, 2012 at 11:06 PM, Mike Belshe < <[email-masked]>
>> [email-masked]> wrote:
>>
>>>   [snip]
> If you have a proxy, the proxy receives the pushes (not the client), so
> the proxy can do whatever it would do in the non push case.
>
> mike
>
>
>>
>> - James
>>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 14:53:24 +0000

In message <CABaLYCusRpEs7bicEq+_jViW5k-X9ehip=[email-masked]>
, Mike Belshe writes:

>But seriously, who are these clients which will reject the pushes?

I think this may be asking the wrong question.

Yes, there will be clients which reject server-push, either because
they only implemented the easy part of the specs, or because the
voices from the tinfoil hat tells them to, but they are not
important.

The people who will have a problem with server-push are the
security people, and the people who have to deal with the
complexity it introduces.

As I understand the desire for server-push it basically is this:

	Client:
		Give me "index.html"
	Server:
		Here it comes, and here are "style.css" and
		"logo.png" which you'll also need.

That makes a lot of sense, but I would solve it this way:

	Client:
		Give me "index.html"
	Server:
		Here is "index.zip" which contains "index.html"
		and some other objects you'll need.

No protocol complexity, the objects are bound together and we
get compression too.  (.zip is just an example though, there
may be better designs, as I assume interleaving might be
desired ?)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 16 Jul 2012 09:20:17 -0700

Bundling has combinatorial explosion problems. It is basically an alternate
server push mechanism.

If we say that we're supposed to look inside the envelope of the bundle,
you end up doing the same as the resource-defined server push that is
implemented in spdy, but you must know about all possible resources that
the dynamic page will generate at the time you create the bundle. This is
basically impossible. You must still advertise which resources will be sent
in the bundle before the user-agent interprets the section of the main
resource which refers to it, else suffer races where the user-agent has
requested an object which is being pushed but has not yet arrived at the
user-agent.

If we don't look in the envelope,  security becomes more difficult. It
becomes costly to do filtering or caching.

Because everything is in one resource, you may not be able to reject
resources as you can with individually identified pushed resources.

-=R

---

From: Mike Belshe <[email-masked]>
Date: Mon, 16 Jul 2012 09:44:03 -0700

> voices from the tinfoil hat tells them to, but they are not

That's why you can't make it optional :-)

> complexity it introduces.

Let me know if you have a specific security question to raise.

> may be better designs, as I assume interleaving might be

OK - we did consider this approach, but it has real problems as you now
have multiple URLs which contain index.html, style.css and logo.png.  It
makes it very difficult to find items in your cache if you allow multiple
URLs to address the same resource.  But worse, it means that you lose the
per-resource response headers that you had before.  So now all 3 of those
items have a single set of cache control headers, which is undesirable.

You could define the zip in a 'smart' way, so that the URLs are preserved
and the client pulls them all apart, but you quickly get into a new
multi-part format which has a lot of subtle nuance (see mime!).

BTW - what you've just described here is basically what 'spriting' does -
combine items in a non-individually addressable way.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 19:24:41 +0000

In message <CAP+FsNcoyx7=[email-masked]>
, Roberto Peon writes:

>but you must know about all possible resources that
>the dynamic page will generate at the time you create the bundle.

Building a zip(-like) archive on the fly has the same complexity
as building the server-push stream, but the benefit of not making
life complex for everybody else.

But yes, it's not without problems, which is why I think we should
stick to the strict request-response model.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 16 Jul 2012 13:03:45 -0700

On Mon, Jul 16, 2012 at 12:24 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <CAP+FsNcoyx7=
> [email-masked]>
> , Roberto Peon writes:
>

With a zip-like archive, you'd not be able to interleave delivery, thus you
cannot change your mind about what should be pushed (if, for instance, one
discovers that multiple things require subresource A and only one thing
requires subresource B), the user-agent cannot cancel receipt/delivery of
the streams, and so instead of potentially wasting at most a BDP's worth of
bytes, we waste potentially the sum of the size of all objects within the
zip-like archive.

I see a significant loss of flexibility and am unclear on the gain.
So, how does a zip-like archive make life easier, and what are the
tradeoffs? What am I missing?

> stick to the strict request-response model.

We know that the trend towards higher available bandwidth continues across
a broad spectrum of the 'net and we know that the speed of light hasn't
appreciably changed.
So, basically, we know that what we have today is significantly imperfect
in a latency sense and getting worse and worse.

We can acknowledge that it is a problem and engineer a solution, or we can
decide to not solve this problem, in which case we'll be forcing everyone
to inline everything all the time. Bleh. Inlining is easy to mess up and
when messed up, can slow down page rendering time horribly.

I see a problem which exists today where we can engineer a solution that
will allow the infrastructure to do the right thing on behalf of the site
developers, which gives much better fine-grained control over which
resources arrive in what order (which is important for above-the-fold user
experience), and which solves the 'empty pipe' problem that currently
exists with HTTP. I'm not in favor of punting on this simply because the
problem is difficult. :)

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 Jul 2012 07:56:19 +0200

Hi Pat,

> the associated-to resource and they "hit" in the micro cache.

It seems to make sense indeed and it's probably the easiest way to
implement it.

Thanks for the insights,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 06:24:10 +0000

>It seems to make sense indeed and it's probably the easiest way to

Uhm, doesn't this lead to incredible cache-bloat ?

	index.html + {style.css, logo.png...}
	article.html?art=1 + {style.css, logo.png...}
	article.html?art=2 + {style.css, logo.png...}
	article.html?art=3 + {style.css, logo.png...}
	...

Or did I misunderstand something ?

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 Jul 2012 08:36:47 +0200

> Or did I misunderstand something ?

You're right, I remember we discussed this point with Robert in Paris.
I think that there should be a way for the client to tell the server
either that it already has some objects (though that's not easy). One
point was that the client can abort the retrieval in one round trip,
so in the end, the worst that may happen is that the download link is
filled with data you already have during one RTT, which means you
download up to the BDP extra data. It can be a concern with overloaded
uplinks though.

I tried to think about ways to avoid this using some date headers in
requests but there is no way you can tell you're up to date with just
this. The referrer might help the server guess you don't need some
shared objects though.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 10:04:46 +0000

>You're right, [...]

That's quite a bummer.

In the scenario where the user-agent has accessed this particular
website previously, there is a very good chance that it has already
cached the extra resources, whereas the first time it accesses
a website, it knows for sure that it hasn't.

That indicates to me that we should put the client in charge.

So why don't we simply give HTTP/2.0 a new primitive, which we
for historical continuity can call "MGET" meaning "send me all
you think I'll need", vs. "GET" meaning "give me just this one" ?

The response to MGET would be perfectly normal objects in all
other respects (but we need to stick their URI in the reponse
somehow.) so caching and all that works normally.

That puts the client squarely in charge of enabling server-push,
makes it trivially easy to avoid it (bots, scripts etc) and
will give the user-agent writers a chance to compete on the
best logic for chosing MGET vs. GET ?

Heck, you could even do that in HTTP/1.1:

	MGET /index.html HTTP/1.1
	Host: example.com
	[...]

	1xx Multiple objects coming your way
	Mget-Object: uri=/style.css, size=23132
	Mget-Object: uri=/index.html size=213123
	Mget-Object: uri=/logo.png size=2394

	200 OK
	[style.css reply]

	200 OK
	[index.html reply]

	200 OK
	[logo.png reply]

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 17 Jul 2012 22:26:18 +1200

> you think I'll need", vs. "GET" meaning "give me just this one" ?

Or "PULL"?  as in "Pull this resource plus associated", "the client-pull 
feature".

> 	Mget-Object: uri=/logo.png size=2394

Now *that* would be an HTTP/1.2 feature. Existing HTTP/1.1 caches would 
relay the 1xx and cache the first 200 under that request. Assigning the 
second 200 to the second pipelined request... and poof. There goes the 
cache integrity.

AYJ

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 17 Jul 2012 10:31:57 +0000

you could maybe just do it with a multipart response.

But IMO limiting server push to only providing associated resources is 
a waste of potential.

Real-time notifications is something I find quite interesting, and that 
would only really work if requested by the client, but then at any 
stage until the connection is closed or whatever, messages could be 
sent.  May not be cachable, but that would make no sense anyway for a 
notification.

Adrien

------ Original Message ------
From: "Amos Jeffries" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 17/07/2012 10:26:18 p.m.
Subject: Re: HTTP2 Expression of Interest : Squid
>Or "PULL"? as in "Pull this resource plus associated", "the 
>client-pull feature". 
>
>
>>
>Now *that* would be an HTTP/1.2 feature. Existing HTTP/1.1 caches 
>would relay the 1xx and cache the first 200 under that request. 
>Assigning the second 200 to the second pipelined request... and poof. 
>There goes the cache integrity. 
>
>AYJ 
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 10:36:21 +0000

In message <em264a739a-df76-4365-be1c-3dd9649ec57a@reboist>, "Adrien de Croy" w

>sent.  May not be cachable, but that would make no sense anyway for a 

But that you can already do, and many apps do: chunked encoding
that just somehow fails to get to the end...

But I think it is imperative that nothing gets sent unless asked
for first, explicitl, by the client.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 17 Jul 2012 10:41:13 +0000

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
>that just somehow fails to get to the end...

problem is you can't tell if an intermediary will rechunk or spool 
until it thinks it has an entire message.

So allowing multiple messages on the stream after a push request by the 
client would allow an intermediary to perform message processing in a 
more deterministic manner.

>for first, explicitl, by the client.

I agree, and actually I'd be keen to apply this philosphy in both 
directions, where no significant resource is transmitted in either 
direction without the recipient indicating prior willingness (either by 
requesting it, or indicating willingness).  What I'm getting at here is 
large POST / PUT requests.  Currently it's a mess esp with auth in the 
mix.

Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 10:49:03 +0000

In message <emc7be1028-2d4d-4336-b386-fbf9464e9559@reboist>, "Adrien de Croy" w
rites:

>I agree, and actually I'd be keen to apply this philosphy in both=20
>directions, where no significant resource is transmitted in either=20
>direction without the recipient indicating prior willingness (either by=20
>requesting it, or indicating willingness).  What I'm getting at here is=20
>large POST / PUT requests.  Currently it's a mess esp with auth in the=20
>mix.

Assuming HTTP/2.0 gets good mux/pipe-lining, I would like to propose
a default limit of max one connection from each client to each server,
until the server transmit a permission to open multiple parallel
connections.

This would take serious steam out of DoS attaks, without affecting
legitimate users.

A similar approach could be used for request body size:  A default
hard limit of X bytes, until the server gives you permission for more.

I know of no web services where you send a 4GB POST point blank, and
certainly none where doing an intial "HEAD /" would be an unbearble
cost.

This would also seriously disarm the DoS bots.

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 17 Jul 2012 16:56:16 +0000

> From: Poul-Henning Kamp [mailto:[email-masked]]
> But I think it is imperative that nothing gets sent unless asked for first,
> explicitl, by the client.

Similar thoughts led us to a client-pull proposal which should also be considered in this space.

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 17 Jul 2012 17:02:24 +0000

> From: Adrien de Croy [mailto:[email-masked]]
...
> I agree, and actually I'd be keen to apply this philosphy in both directions,
> where no significant resource is transmitted in either direction without the
> recipient indicating prior willingness (either by requesting it, or indicating
> willingness).  What I'm getting at here is large POST / PUT requests.  Currently
> it's a mess esp with auth in the mix.

Along these lines, to help with a  POST/PUT with auth in the mix we mentioned an idea in our authentication EoI of a lightweight probe:

http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0239.html:

1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs with long entity bodies will cause problems because of the extra round trip required by authentication. ("Initial" means when first request on a connection is PUT or POST). If the body is indefinite length, it may not be able to be recreated. This is a problem with any multi-legged authentication scheme in HTTP. It could be avoided if there were a guaranteed benign request type that could be used to force authentication if needed before doing the PUT or POST.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Jul 2012 19:17:57 +0200

> 1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs with long entity bodies will cause problems because of the extra round trip required by authentication. ("Initial" means whe…

We have

   Expect: 100-continue

for that, no?

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 10:55:59 -0700

On Tue, Jul 17, 2012 at 10:17 AM, Julian Reschke <[email-masked]>wrote:

>>> directions,
>> Along these lines, to help with a  POST/PUT with auth in the mix we
>> mentioned an idea in our authentication EoI of a lightweight probe:
>>
>> http://lists.w3.org/Archives/**Public/ietf-http-wg/**2012JulSep/0239.html<http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0239.html>
>> :
>>
>> 1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs
>> with long entity bodies will cause problems because of the extra round trip
>> required by authentication. ("Initial" means when first request on a
>> connection is PUT or POST). If the body is indefinite length, it may not be
>> able to be recreated. This is a problem with any multi-legged
>> authentication scheme in HTTP. It could be avoided if there were a
>> guaranteed benign request type that could be used to force authentication
>> if needed before doing the PUT or POST.
>>
>
> We have
>
>   Expect: 100-continue
>
> for that, no?
>
>
Heh... I suggested that yesterday and was told that I was being silly.

I've been kicking around the idea of a new PUSH* method whose semantics,
quite literally, are: Here's a bag of bits I want to send you. (*My
instinct is that POST could work just as well). The PUSH would consist
initially of a HEADERS frame containing a basic manifest of the content the
sender wishes to send... Once the manifest is sent, the send sends each bit
of content preceded by a HEADERS frame that provides the detail of the
content... essentially a form of multipart entity that uses HEADERS and
DATA frames for delineation. The HEADERS frame for each piece of content
would provide information such as ETag, Last-Modified, Content-Location,
Content-Type and Cache-control for each individual piece of content
delivered. If the recipient determines that it either already has a
particular piece of content or doesn't want it for whatever reason, the
recipient has the option of canceling out of the stream at any time.

Example.. sender wants to push two items... recipient oks the transfer ...
note that the sender doesn't have to wait for the SYN_REPLY to begin
sending the data...

=> SYN_STREAM (:method=PUSH)
=> HEADERS (
     Content:[
       (Content-Location: ..., ETag: ...),
       (Content-Location: ....,ETag: ...)
   )

<= SYN_REPLY (:status: OK)

=> HEADERS (
     Content-Location: ...,
     Content-Type: ...,
     ETag: ....,
     Last-Modified: ....)

=> DATA
=> DATA
=> DATA

=> HEADERS (
     Content-Location: ...,
     Content-Type: ...,
     ETag: ....,
     Last-Modified: ....)

=> DATA
=> DATA
=> DATA (fin)

<= DATA (fin)

This approach work in both directions... e.g. server-push and client-push
(uploading files). It also provides the recipient with enough additional
information to handle caching, and gives the recipient the opportunity to
tell the sender no. To be useful, the manifest would need to have enough
useful information to allow the recipient to determine if it needs the
content or not (e.g. is the same version already cached?).

Yes, this adds significant complexity to the problem so I'm not sure if
this strategy would work or not but I'm experimenting with it at least.

Server push is good, but the client needs to be allowed to opt out at any
time.

- James

Best regards, Julian

---

From: Osama Mazahir <[email-masked]>
Date: Tue, 17 Jul 2012 19:45:11 +0000

As it is currently, 100-continue is problematic.  The situation is tricky because the client is not forced to wait for the 100/417/4xx (i.e. client is allowed to timeout and send the entity body).  Thus, the server does not have a deterministic way to now if the next byte after the double CRLF is the first byte of the next request or the first byte of the entity body (of the initial request).  This results in connections getting closed in various edge/error cases.

100-continue is almost there but if we wanted to use it in a robust manner in HTTP2 then I think we would have to revisit its specification.

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 10:18 AM
To: Gabriel Montenegro
Cc: Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; [email-masked]
Subject: Re: HTTP2 Expression of Interest : Squid

On 2012-07-17 19:02, Gabriel Montenegro wrote:
>> direction without the recipient indicating prior willingness (either 
>> by requesting it, or indicating willingness).  What I'm getting at 
>> here is large POST / PUT requests.  Currently it's a mess esp with auth in the mix.
>

We have

   Expect: 100-continue

for that, no?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Jul 2012 22:31:08 +0200

> 100-continue is almost there but if we wanted to use it in a robust manner in HTTP2 then I think we would have to revisit its specification.

Well, we are revising RFC 2616, and if something is broken here we 
should consider to fix it. Or, minimally, document the problem.

If I understand correctly, this will happen if the client sends "Expect: 
100-continue", the server is slow to return an error status, and the 
client decides to give up waiting for the 100 status, and continues?

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 13:42:57 -0700

The 100-continue stuff is really poor flow control, from my perspective.
Also, I've yet to meet an implementor who even likes 100-continue because
it messes with the idea of a request-response model. It should be metadata
and was a nasty nasty hack. Phooey! :)

The idea of MGET vs GET amounts to making something optional.

If you do that there will be clients that didn't implement it because
they're lazy.

I have little desire to cater to lazy client implementors and incomplete
spec implementations-- They can stick with HTTP/1.1.
I care strongly about the user and the user experience.
I fight (and create, blah blah) for the users!

If we make this optional, one of these is likely to happen
1) We increase the amount of inlining that people do, because it is the
easiest way to deal with cold page load time, especially for mobile devices.
2) Nobody implements the feature because optional features are often poorly
tested and the cost/benefit causes this to converge in a negative feedback
loop. The feature becomes unused.
3) Latency is worse than it could be across a number of different use
cases, one interesting one is a redirect.

If anyone is under the illusion that the client has any control over what
it receives, I'd like to disabuse them now.
Any content creator can put whatever they want into any resource, making it
whatever size they'd like at any time.
The client gets to decide to call recv() or not. It controls what resource
it requests. That is it, really. It can't call close() unless it wishes to
abandon the resource it is loading which in the inlining case would be the
main resource.

Thusfar with server-push, we're proposing to give the client another knob--
it can tell the server to stop sending stuff it doesn't like. It gives
clients and proxies more flexibility to identify and filter.
It can do so without causing the session to restart, which is important.
Restarting the session is costly in terms of latency to the client, battery
to the device, and CPU to the server.

The idea that the client can announce whether or not it wants a push does
not end with the scenario where the client just gets object A. It results
in a scenario where the client gets object A with mix-ins from B,C,D..N as
unidentifiable, difficult to filter and impossible to  blobs.

Sites and content-providers are not incented to get this wrong, but doing
it the way we have today makes the problem of optimizing pages far, far
more difficult that it should be.

-=R

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 13:50:37 -0700

On Tue, Jul 17, 2012 at 10:55 AM, James M Snell <[email-masked]> wrote:

>>> http://lists.w3.org/Archives/**Public/ietf-http-wg/**
>>> 2012JulSep/0239.html<http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0239.html>
>>> :
>>>
You've roughly described the first server push that we played with! :)

The problems we found with this:
1) Often servers will begin sending data before they've computed the
dynamic bit. As a result, you'll need to be able to mention at any time,
that you're going to promise to push something. You can't assume you'll
know the entire list of resources at any point until the request is done,
and you'll wanting to be stuffing bits into the pipe before that happens if
there is dead air.
2) You'll want to promise a push without bloating the fetch latency for the
requested resource. This means that you'll want to send as little as is
possible to identify to the browser what is to be pushed, and after the
main resource has been sent, then begin pushing the rest.
3) Sometimes, you'll want to change your mind. You were pushing a number of
images that the user is going to use, but you discovered that they need
some essential javascript instead. You should be able to interrupt the
lower priority data with the higher priority data so that you soften or
eliminate the effect of non-optimal mentions or ordering of resources in
the page.
4) For some content, sending the first N bytes with a higher priority than
the rest of the resource results in a usable page far sooner. This is very
interesting for many .jpgs and similar resources that can refine as more
data is pushed.

> this strategy would work or not but I'm experimenting with it at least.

cool!

> Server push is good, but the client needs to be allowed to opt out at any

Why?
-=R

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 13:58:01 -0700

I don't think the spec itself is broken; it is just difficult to get the
web as a whole to do it right, probably because it totally breaks
request-response assumptions. :(
-=R

On Tue, Jul 17, 2012 at 1:31 PM, Julian Reschke <[email-masked]>wrote:

>> As it is currently, 100-continue is problematic.  The situation is tricky
>> because the client is not forced to wait for the 100/417/4xx (i.e. client
>> is allowed to timeout and send the entity body).  Thus, the server does not
>> have a deterministic way to now if the next byte after the double CRLF is
>> the first byte of the next request or the first byte of the entity body (of
>> the initial request).  This results in connections getting closed in
>> various edge/error cases.
>>
>> 100-continue is almost there but if we wanted to use it in a robust
>> manner in HTTP2 then I think we would have to revisit its specification.
>> ...
>>
>
> Well, we are revising RFC 2616, and if something is broken here we should
> consider to fix it. Or, minimally, document the problem.
>
> 100-continue", the server is slow to return an error status, and the client
> decides to give up waiting for the 100 status, and continues?
>
> Best regards, Julian
>
>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 Jul 2012 22:59:22 +0200

On Tue, Jul 17, 2012 at 10:31:08PM +0200, Julian Reschke wrote:
> >As it is currently, 100-continue is problematic.  The situation is 
> >tricky because the client is not forced to wait for the 100/417/4xx 
> >(i.e. client is allowed to timeout and send the entity body).  Thus, the 
> >server does not have a deterministic way to now if the next byte after 
> >the double CRLF is the first byte of the next request or the first byte 
> >of the entity body (of the initial request).  This results in 
> >connections getting closed in various edge/error cases.
> >

I don't see how it is possible to send a next request without first sending
the entity body, the message is not complete until it has been sent as a
whole; the problem could only happen if the server wished to reject the
expectation (4xx).

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Jul 2012 23:04:37 +0200

> whole; the problem could only happen if the server wished to reject the

Exactly. So why, *in practice*, would it take the server so long to 
return the 4xx?

(Just trying to understand whether this is a problem in practice, and if 
it is, what we could do about it -- recommend a minimal timeout?)

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 14:12:30 -0700

Clients want to have small timeouts when possible, partially because of
poor behavior of NATs when they lose the mapping and begin black holing
traffic.
Its all a race.

-=R

On Tue, Jul 17, 2012 at 2:04 PM, Julian Reschke <[email-masked]>wrote:

> Exactly. So why, *in practice*, would it take the server so long to return
> the 4xx?
>

---

From: Osama Mazahir <[email-masked]>
Date: Tue, 17 Jul 2012 22:32:58 +0000

It's not broken as long as we are OK that the connection has to be closed upon expectation rejection (for non-chunked entity-body).

Based on my understanding, the client must close the connection if the server replied with a 4xx [1] against a non-chunked request.  Which makes sense as it ensures message integrity on a persistent connection [2].  Essentially, we break the ambiguity by having the server assume that the next byte (after the CRLFCRLF) will be entity-body.  If the client timed out and blasted the entity-body, then the server can drain it and drop on the floor so as to start parsing the next request.  If the client didn't timeout then it can close the connection and start a new one for the next request (or perhaps even deliberately send the entity-body if it believes it is cheaper to send the irrelevant entity-body instead of warming a new connection).  If the entity-body was chunked, then the client can 0-terminate it and start the next request [1].

My concern was whether using 100-continue as the mechanism for an auth-probe is really the best approach.  It might make the world simpler if, in HTTP/2.0, 100-continue didn't have timeouts, which would also increase connection persistence (because after server sends 4xx, server would deterministically know that the next received byte will be the start of the next request and the client is not forced close the connection).  Sending a POST with "Expect:100-continue", getting a 401 back and then having to close the connection seems poor [3].

I don't think we need to design a solution right now, but instead just realize that some solution for auth-probing might be a good idea.

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-6.4.2
[2] "In order to remain persistent ...": http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-6.3.2.1
[3] I realize this may not be relevant if initiating a new request/stream/channel/etc is super cheap.

From: Roberto Peon [mailto:[email-masked]]
Sent: Tuesday, July 17, 2012 2:13 PM
To: Julian Reschke
Cc: Willy Tarreau; Osama Mazahir; Gabriel Montenegro; Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; [email-masked]
Subject: Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

Clients want to have small timeouts when possible, partially because of poor behavior of NATs when they lose the mapping and begin black holing traffic.
Its all a race.

-=R
On Tue, Jul 17, 2012 at 2:04 PM, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

Exactly. So why, *in practice*, would it take the server so long to return the 4xx?

(Just trying to understand whether this is a problem in practice, and if it is, what we could do about it -- recommend a minimal timeout?)

Best regards, Julian

---

From: Paul Leach <[email-masked]>
Date: Wed, 18 Jul 2012 00:06:22 +0000

Other people have covered most of the issues in other posts. 
Also, as RFC 2616 says: 
        Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
Hence, even if HTTP/2.0 creates an ironclad spec, if the first thing the client does is a PUT, the client won’t know that it isn't talking to an HTTP/2.0 server until it is too late.

An quick-and-dirty  example of an approach I had in mind that might work is a new AUTH-* family of methods with a request line that looks like
                AUTH-method Request-URI HTTP/1.1 
e.g.
	AUTH-PUT /someresource HTTP/1.1
which will return 401 if authentication would be required if "method" was invoked on the Request-URI, 200 if not, and 501 if the server doesn’t understand the AUTH-* methods.

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2012 10:18 AM
To: Gabriel Montenegro
Cc: Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; [email-masked]
Subject: Re: HTTP2 Expression of Interest : Squid

We have

   Expect: 100-continue

for that, no?

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 17:16:33 -0700

AUTH-PUT? Eww... for far too many reasons to list. Using a new method for a
revised content-push/expect/continue type of mechanism does make sense,
however, as it avoids the type of miscommunication that could happen when
attempting to interact with downlevel servers. A single "PUSH" method, as I
described previously, with semantics defined strictly for HTTP/2.0 should
be enough to address the issue.

- James

On Tue, Jul 17, 2012 at 5:06 PM, Paul Leach <[email-masked]> wrote:

> Hence, even if HTTP/2.0 creates an ironclad spec, if the first thing the
> client does is a PUT, the client won’t know that it isn't talking to an
> HTTP/2.0 server until it is too late.
>
> An quick-and-dirty  example of an approach I had in mind that might work
> is a new AUTH-* family of methods with a request line that looks like
> which will return 401 if authentication would be required if "method" was
> invoked on the Request-URI, 200 if not, and 501 if the server doesn’t
> understand the AUTH-* methods.
>

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 10:48:21 -0500

I don't think the spec is broken on 100-continue.

However, as a practical matter, how many servers *really* support the
mechanism? As far as I know, all major Java implementations
immediately send back a "HTTP/1.1 100 Continue\r\n\r\n" response if
the request carries header "Expect: 100-continue". Therefore they
support the feature on paper, yet completely defeat its purpose.

Zhong Yu

On Tue, Jul 17, 2012 at 3:31 PM, Julian Reschke <[email-masked]> wrote:
>> because the client is not forced to wait for the 100/417/4xx (i.e. client is
>> allowed to timeout and send the entity body).  Thus, the server does not
>> the initial request).  This results in connections getting closed in various
>> edge/error cases.
>>
>> 100-continue is almost there but if we wanted to use it in a robust manner
>> in HTTP2 then I think we would have to revisit its specification.
>> ...
>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 18:20:23 +0200

> support the feature on paper, yet completely defeat its purpose.

I believe Jetty does the right thing (it waits until the servlet 
actually gets the input stream).

And yes, it *is* very frustrating that the servlet EG apparently hasn't 
defined this yet (although I have to admit that I have given up on 
checking).

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 00:09:10 +0200

On Tue, Jul 17, 2012 at 10:32:58PM +0000, Osama Mazahir wrote:
> It's not broken as long as we are OK that the connection has to be closed
> upon expectation rejection (for non-chunked entity-body).
> 
> Based on my understanding, the client must close the connection if the server
> replied with a 4xx [1] against a non-chunked request.  Which makes sense as
> it ensures message integrity on a persistent connection [2].  Essentially, we
> break the ambiguity by having the server assume that the next byte (after the
> CRLFCRLF) will be entity-body.

You're right indeed, the protocol is broken in this case depending on whether
the client gets the 4xx in time and refrains from sending the body, or if it
starts sending the body before receiving the 4xx.

The protocol does not allow us to tell what the server will get depending on
the timing (either body or next request).

I think we should state that upon 4xx in response to Expect: 100-Continue,
the server should close the connection (after draining possibly pending data),
just as it would do on a redirect to another domain for instance.

That's an interesting case. I don't know how haproxy handles it, I suspect
it could be tricky.

Regards,
Willy

---

From: Osama Mazahir <[email-masked]>
Date: Fri, 20 Jul 2012 00:32:11 +0000

> I think we should state that upon 4xx in response to 
> Expect: 100-Continue, the server should close the connection 
> (after draining possibly pending data), just as it would do 
> on a redirect to another domain for instance.
>
> That's an interesting case. I don't know how haproxy handles 
> it, I suspect it could be tricky.

I think the current state is fine.  The current text says "If it responds with a final status code, it MAY close the transport connection or it MAY continue to read and discard the rest of the request."  Windows tries to leave the connection open (i.e. of course, upper layer can always override or we may have hit an non-continuable error such as corrupted request).  This allows the server to handle the following cases:
1) Client sent the entity-body before getting the expect-answer (e.g. timeout).
2) Client believes it is more efficient to send irrelevant entity-body instead of tearing down and warming up a new connection.
3) Client was sending a chunked entity-body and can gracefully indicate request end with a zero chunk.

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2012 3:09 PM
To: Osama Mazahir
Cc: Roberto Peon; Julian Reschke; Gabriel Montenegro; Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; [email-masked]
Subject: Re: usability of 100-continue, was: HTTP2 Expression of Interest : Squid

On Tue, Jul 17, 2012 at 10:32:58PM +0000, Osama Mazahir wrote:
> It's not broken as long as we are OK that the connection has to be 
> closed upon expectation rejection (for non-chunked entity-body).
> 
> Based on my understanding, the client must close the connection if the 
> server replied with a 4xx [1] against a non-chunked request.  Which 
> makes sense as it ensures message integrity on a persistent connection 
> [2].  Essentially, we break the ambiguity by having the server assume 
> that the next byte (after the

You're right indeed, the protocol is broken in this case depending on whether the client gets the 4xx in time and refrains from sending the body, or if it starts sending the body before receiving the 4xx.

The protocol does not allow us to tell what the server will get depending on the timing (either body or next request).

I think we should state that upon 4xx in response to Expect: 100-Continue, the server should close the connection (after draining possibly pending data), just as it would do on a redirect to another domain for instance.

That's an interesting case. I don't know how haproxy handles it, I suspect it could be tricky.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 14:19:16 +1200

> just as it would do on a redirect to another domain for instance.

Why should a redirect to another domain have any relevance to the 
connection state? What if the client was a proxy which collated many 
client requests for htp://example.com/, each of which needed redirecting 
to http://example.net/ ?

> That's an interesting case. I don't know how haproxy handles it, I suspect

Always assume its the entity body when one is expected. Only listen to 
explicit client signals that there is none. Such as a close(), last 
bytes of content-length arriving, zero-chunk, or non-chunk.

There are other players in the game as well. Transfer-Encoding gzip, 
deflate, compress appear to contain no markers which would indicate end 
of object to servers - yet being Transfer-Encoding they usually cannot 
be accompanied by content-length. AFAICT the only reliable marker they 
have is close().

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 08:02:38 +0200

On Fri, Jul 20, 2012 at 12:32:11AM +0000, Osama Mazahir wrote:
> I think the current state is fine.  The current text says "If it responds
> with a final status code, it MAY close the transport connection or it MAY
> continue to read and discard the rest of the request."  Windows tries to
> leave the connection open (i.e. of course, upper layer can always override or
> we may have hit an non-continuable error such as corrupted request).  This
> allows the server to handle the following cases:
> 2) Client believes it is more efficient to send irrelevant entity-body
> instead of tearing down and warming up a new connection.

But it does not cover the client which immediately receives the 417 and
which refrains from sending and instead reuses the connection.

It is all a matter of race condition : depending on the RTT between the
client and the server, the exact same sequence of operations at both sides
may lead to a different behaviour :
  - only headers are sent, client does not send body and goes on with next
    request ;
  - body starts to be sent and server has to drain it.

So the server cannot detect whether what follows is a body or a next
request.

I suspect that sending request-looking data in a POST with an Expect
header might produce interesting results which merit being studied on
various products :

   POST /public HTTP/1.1
   Host: www.example.com
   Expect: 100-Continue
   Content-Length: 100

   GET /private HTTP/1.1
   Host: www.example.com

In my opinion the only way to remain safe would be to systematically
close the connection after a 4xx. However it could cause problems with
connection-based authentication such as NTLM. It does not look like a
trivial problem.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 08:08:46 +0200

On Fri, Jul 20, 2012 at 02:19:16PM +1200, Amos Jeffries wrote:
> >>server

The proxy use-case is a valid one. Still, I've observed many times that
some servers close the connection on redirects to external hosts. Now
whether it's the application which adds a "connection: close" or the
framework which does this for free, I don't know. The reason clearly is
that the browser is not expected to reuse the connection when going away,
which is not true at all when the client is a proxy, as you noted.

> bytes of content-length arriving, zero-chunk, or non-chunk.

The issue is if the client is allowed to reuse the connection after it
receives an 4xx without sending the body. So the examples you give are
the ones that work well :-)

>From what I remember of my last reading of draft-19, it was clearly stated
that if a transfer-encoding other than chunked is present, then chunked MUST
be present last so the transfer is always chunk-encoded, precisely for this
issue. You can send safely reject messages which contain Transfer-Encoding
without "chunked" as the last one (you'd better recheck the spec than take
my word for it though).

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 18:45:15 +1200

> which is not true at all when the client is a proxy, as you noted.

The key word in there is probably "browser", the assumption that each 
client is singular ("browser") and that each connection is singular 
("user") is very widespread.

That is no reason for any compliant server to disconnect. Let the broken 
servers do it, and let the correct servers gain the benefits of being 
correct.

Referring to this part specifically: "the server should close the 
connection (after draining possibly pending data), just as it would do 
on a redirect to another domain"

> without "chunked" as the last one (you'd better recheck the spec than take

There is no mandate that chunked is *always* to be used with them 
though. Only that when combined the best is last.

We have had to take that assumption on our own guess at good-practice in 
Squid and decoded to always chunk 1.1 when content-length is missing. 
Regardless of other encodings.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 09:08:08 +0200

> servers do it, and let the correct servers gain the benefits of being 

+1 on this.

> though. Only that when combined the best is last.

Yes, I just found it :

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.1

   If any transfer-coding is applied to a
   request payload body, the final transfer-coding applied MUST be
   "chunked". If any transfer-coding is applied to a response payload
   body, then either the final transfer-coding applied MUST be "chunked"
   or the message MUST be terminated by closing the connection.

> Regardless of other encodings.

I think this was recent additions from http-bis (which is a very important one).

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 19:28:47 +1200

> which refrains from sending and instead reuses the connection.

Did you mean the tricky case where encoding is attempted and the 417 
returns. For chunked the server does not support detecting a zero-length 
chunk as an aborted entity. But the client requires it to keep-alive. So 
the option there is client closure if it arrives late and server 
required to assume the next bytes after header are a new header set.
   Note that a zero-length chunk is "0CRLF" which is not a valid HTTP 
request-line even when assuming HTTP/0.9 compatibility. The other 
transfer encodings result in binary data which is also not valid 
request-method. The server aborting the connection on invalid 
next-request seems to take effect in that case regardless of encoding.

When the race is lost the server barfs and closes. When the race is won 
the client goes right to next request and the keep-alive works fine.

The key though is for the client to *always* continue with the attempted 
operation on a timeout. If the server does not reject it fast enough too 
bad.

Could we mandate a minimum client timeout suitable for slow high latency 
connections. Or suggest that it is linked to RTT somehow? as you say it 
is RTT related race, making a timeout depend on RTT seams reasonable if 
possible.

> header might produce interesting results which merit being studied on

In the above example the use of content-length requires that the server 
drain 100 bytes regardless of what the client does.

> connection-based authentication such as NTLM. It does not look like a

On NTLM the initial www-auth scheme advertisement can safely be closed. 
It's inefficient but safe.
The first handshake responses is where trouble comes in, and by that 
time the client should have stopped attempting Expect.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 19:37:54 +1200

On 20/07/2012 7:08 p.m., Willy Tarreau wrote:
>     "chunked".

Wait up!  there is an implication in here I overlooked.

"If any transfer-encoding is applied ... the final ... applied MUST be 
chunked."

That is not very clear, but definitely mandatory chunked encoding on 
requests. Which resolves all the weird edge cases by making the next 
bytes a chunked size field which is invalid requst-line syntax.

>   If any transfer-coding is applied to a response payload

It would seem so.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 09:52:29 +0200

On Fri, Jul 20, 2012 at 07:28:47PM +1200, Amos Jeffries wrote:
> returns.

no, see with the example below :-)

> is RTT related race, making a timeout depend on RTT seams reasonable if 

Application never have any idea of RTT, especially when they're behind
reverse-proxies.

> drain 100 bytes regardless of what the client does.

Exactly. The problem is that the client is not forced to send data on a
failed expectation (which is the purpose). Imagine with the example above :

   Client                                                           Server
        -------------------- request headers ------------------------>

        <----------- 417 failed --------------------------------------

        ------ no body, then go on with next request ---------------->

Or :

   Client                                                           Server
        -------------------- request headers ------------------------>

                                      ... <------ 417 failed ---------
        ---------- tired of waiting, sending body ------------------->
        <------ 417 failed ------ ...

In both situations, the server receives something after it has sent 417.
In one case it's the next request and in the other case it's the body.
It could be the same with 401 BTW.

So after a failed expectation with a content-length, the connection must
not be reused. Chunked encoding does not have this issue however since
the end of the message is always known.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Jul 2012 22:44:16 +1200

> the end of the message is always known.

That is still a content-length case though (absene of encoding type). 
Part 1 section 3.3.3 point #5.  In all of those cases content-length 
amount of bytes MUST be sent or the connection aborted.
417 is a final response to that initial request. Therefore the server 
drains the content-length body and connection re-use can begin. Client 
is responsible for aborting the connection or padding with disposable 
garbage bytes.  At no point can the client send content-length then 
re-use the connection earlier.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 14:58:04 +0200

> amount of bytes MUST be sent or the connection aborted.

OK, too much noise from me then, sorry.

> re-use the connection earlier.

That's fine then.

Thanks for the pointer,
Willy

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 09:26:31 -0700

> > drain 100 bytes regardless of what the client does.

So this would be yet another argument in favor of spdy-style framing and
multiplexing

Consider, for instance,

Client                  Server
  |                       |
  |======================>|
  | 1) SYN_STREAM         |
  |   id=1                |
  |   method=POST         |
  |   expect=100          |
  |   content-length:100  |
  |                       |
  |======================>|
  | 2) SYN_STREAM         |
  |   id=3                |
  |   method=GET          |
  |                       |

Due to the multiplexed framing model, the client can proceed with Stream #3
without waiting for the server to respond to the POST and without worrying
about whether the server will drop the data on the floor due to the
content-length header. If the server takes too long to respond to Stream
#1, it can attempt to go ahead and send the Stream #1 Data frames or it can
abandon the stream with a RST_STREAM without requiring the connection to be
killed off.

That said, fwiw, HTTP/1.1 clients are not supposed to be pipelining
non-idempotent methods anyway, so sending a GET on the same connection as a
POST, especially one that is using Expect: 100 is simply bad form.

- James

---

From: Roberto Peon <[email-masked]>
Date: Fri, 20 Jul 2012 09:41:58 -0700

I wish that POST actually meant "here is something that changes state" and
GET meant "nope,  of changing any state", but both are lies today as far as
I can tell.

POST generally means : here is  form input or here is a file, which
sometimes changes state and sometimes doesn't.

I believe this failure to be the result of not exposing rich enough (and
fully HTTP) semantics to the browser JavaScript and thus having forced the
web application writers to make do with what they had.

I believe at this point that we should probably amend the spec to state the
common practice as a warning to anyone who makes assumptions about
idempotency.

Bleh.

-=R
On Jul 20, 2012 9:26 AM, "James M Snell" <[email-masked]> wrote:

> Due to the multiplexed framing model, the client can proceed with Stream
> #3 without waiting for the server to respond to the POST and without
> worrying about whether the server will drop the data on the floor due to
> the content-length header. If the server takes too long to respond to
> Stream #1, it can attempt to go ahead and send the Stream #1 Data frames or
> it can abandon the stream with a RST_STREAM without requiring the
> connection to be killed off.
>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 19:59:31 +0200

> sometimes changes state and sometimes doesn't.

For some developers it's even worse : "GET is cacheable while POST isn't" !
When you hear this you know you have a long road to go to help them fix
their issues...

> common practice as a warning to anyone who makes assumptions about

I think the current spec is already clear on this, but maybe at one point
we should collect most common urban legends and drop them into a separate
RFC.

Willy

---

From: Zhong Yu <[email-masked]>
Date: Fri, 20 Jul 2012 14:09:24 -0500

Some small problems with the spec:

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-20#section-4.6.14

The meaning of 417 is vague. If a server isn't interested in the body
of a request with "Expect: 100-continue", SHOULD the server send 417?
I don't think so, there can be many reasons why the server isn't
interested in the body; it should send a specific response code
reflecting the real reason, e.g. 403.

Server's intent that the client does not send the body is already
expressed by not sending 100 before the final code; there's no value
in 417 repeating that intent.

Then 417 is only useful when the server cannot understand the expectation.

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-6.4.3
Requirements for HTTP/1.1 origin servers:
  ... (the server) MUST NOT perform the request method if it returns a
final status code (without a prior 100)

That's too harsh, isn't it? Though the server doesn't need to read the
request body, that doesn't mean the request cannot be served. Maybe
the request headers contains sufficient information, and the request
body is just a redundancy measure.

Zhong Yu

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jul 2012 21:20:06 +0200

> Then 417 is only useful when the server cannot understand the expectation.

Indeed. See also:

"Upon receiving a request which includes an Expect header field with the 
"100-continue" expectation, an origin server MUST either respond with 
100 (Continue) status code and continue to read from the input stream, 
or respond with a final status code. The origin server MUST NOT wait for 
the request body before sending the 100 (Continue) response. If it 
responds with a final status code, it MAY close the transport connection 
or it MAY continue to read and discard the rest of the request. It MUST 
NOT perform the request method if it returns a final status code." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.6.4.3>

> body is just a redundancy measure.

That appears to be an edge case not worth optimizing for.

Best regards, Julian

---

From: Zhong Yu <[email-masked]>
Date: Fri, 20 Jul 2012 14:35:00 -0500

What are the reasons for such great efforts to keep connection alive
when a 100-continue fails? Is it really a big deal to drop connections
once in a while?

If the client receives a final code, not 100:

1. before sending the request body - it should not send the body.
2. during sending the request body - it should immediately stop
sending the body any further.

In both cases, the client should close the connection after the final
response is read. It should not fake a graceful end-of-body with a
0-chunk, because that is lying - to the observers, it seems that the
client successfully sends a complete body, and the body content is
such.

3. after sending the request body - no problem here, connection remains good.

If the server does not respond with a 100, it should close the
connection after the final response is written. There is no point to
attempt to read till the end of request body - that will fail anyway
in most cases. If the client is mischievous and continues to send the
body, server will be on a fool's errand to consume the useless bytes.
That'll waste more resources than simply drop the connection.

Zhong Yu

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 21:46:47 +0200

> when a 100-continue fails? Is it really a big deal to drop connections

Some webservice clients make extensive use of Expect: 100-continue over
connection pools to avoid sending useless data and to keep the connections
open. In fact, we're realizing that in the end it does not work (unless
chunked encoding is used).

In the end, these WS clients might as well not send Expect and save one
round trip and one packet in each direction since the only benefit of
it goes away in case of failure, which is the only reason for using
Expect.

Regards,
Willy

---

From: James M Snell <[email-masked]>
Date: Fri, 20 Jul 2012 12:53:30 -0700

> chunked encoding is used).
+1 .. I've had similar experience. It's one of those things that sounds
great in theory but in practice it just doesn't work effectively... at
least not well enough to justify it's use.

- James

---

From: Zhong Yu <[email-masked]>
Date: Fri, 20 Jul 2012 15:20:47 -0500

I always feel that this mechanism - ask permission first - should be
addressed by the app protocol, not by HTTP.

On Fri, Jul 20, 2012 at 2:53 PM, James M Snell <[email-masked]> wrote:
> great in theory but in practice it just doesn't work effectively... at least
> not well enough to justify it's use.
>
> - James
>
>>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 20 Jul 2012 22:24:43 +0200

> addressed by the app protocol, not by HTTP.

Except that it's more expensive at the application layer as it requires
two HTTP requests to have it right. And conditions might change between
the two requests, especially if a load balancer in the middle switches
the server between the two requests.

HTTP is there to abstract the transport channel to the application layer,
let's ensure it does it right if we can.

Anyway this limitation is properly described in draft-20 so this is fine.
It's just another trap developpers will need to be aware of.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 21 Jul 2012 11:31:45 +1200

On 21/07/2012 7:20 a.m., Julian Reschke wrote:
> "Upon receiving a request which includes an Expect header field with 
> the "100-continue" expectation, an origin server MUST either respond 
> with 100 (Continue) status code and continue to read from the input 
> stream, or respond with a final status code. The origin server MUST 
> NOT wait for the request body before sending the 100 (Continue) 
> response. If it responds with a final status code, it MAY close the 
> transport connection or it MAY continue to read and discard the rest 
> of the request. It MUST NOT perform the request method if it returns a 
> final status code." -- 

In isolation this appears to be translatable as:
   MUST NOT perform method if final status (200) is returned without 
prior 100-continue (ie HTTP/1.0 hop erased Expect)

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 21 Jul 2012 11:48:04 +1200

On 21/07/2012 7:53 a.m., James M Snell wrote:
>
>
> On Fri, Jul 20, 2012 at 12:46 PM, Willy Tarreau <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> +1 .. I've had similar experience. It's one of those things that 
> sounds great in theory but in practice it just doesn't work 
> effectively... at least not well enough to justify it's use.
>
> - James

Depends on what the application considers to be its use-case.

For those of you shavign off RTT, it breaks your ideal situation by 
adding RTT.

For services where TCP TIME_WAIT from closure is some large multiple of 
RTT, the single RTT added by Expect is saved many times over by total 
throughput capacity on the re-usable connection. Particularly since 
those types of connections are usually only seen between two piece of 
high-performance middleware and not by the end-user or origin server. In 
such middleware Connection:close is a major problem impacting many other 
users, not just the one being very helpful by sending Expect.

>     it goes away in case of failure, which is the only reason for using

+1. For these cases. It makes little sense to use Expect: without 
chunked or some other nice way to early-abort the entity when the race 
is lost.

Amos

---

From: Zhong Yu <[email-masked]>
Date: Fri, 20 Jul 2012 20:05:32 -0500

On Fri, Jul 20, 2012 at 6:31 PM, Amos Jeffries <[email-masked]> wrote:
>> "100-continue" expectation, an origin server MUST either respond with 100
>> (Continue) status code and continue to read from the input stream, or
>> respond with a final status code. The origin server MUST NOT wait for the
>> request body before sending the 100 (Continue) response. If it responds with
>> a final status code, it MAY close the transport connection or it MAY
>> continue to read and discard the rest of the request. It MUST NOT perform
>> the request method if it returns a final status code." --
>   MUST NOT perform method if final status (200) is returned without prior
> 100-continue (ie HTTP/1.0 hop erased Expect)

"The server does not want the request body" has no logical implication
that "the server does not want the request". We shouldn't dictate what
the server must do here. It can do whatever it wants to with the
request, and what it actually did is reflected in the final response.

Zhong Yu

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 21 Jul 2012 07:26:50 +0200

> request, and what it actually did is reflected in the final response.

I don't think this is appropriate, because it will imply that the client
must send the correct body then, just in case the server decides to use
it.

If the client uses chunked encoding, it can very well send a 0CRLF as
soon as it receives the 4xx, which will truncate the body. Similarly,
a client using content-length might prefer sending zeroes because it's
easier for it than transfering correct data.

Willy

---

From: "Martin Nilsson" <[email-masked]>
Date: Mon, 30 Jul 2012 01:58:50 +0200

On Mon, 16 Jul 2012 16:19:36 +0200, Mike Belshe <[email-masked]> wrote:

> Making it a client decision kills the feature entirely.  We

I'll disagree with you from two different directions...

First of all I think it would be useful if a client could set up a  
subscription on a resource or a set of resources. I guess you could  
associate the resources with the subscription request, but the duration  
would be different than from a normal request (e.g. for the duration of  
the connection). This is obviously outside of the scope of HTTP semantics,  
but it would be nice if the infrastructure was in place on a binary level  
(e.g. current SPDY/3 can be twisted to support it).

Secondly, if I disable javascript and images, override CSS and turn on  
on-demand-plugins there are very few relevant resources the server can  
push (frame documents and favicons). The issue is for the server to  
determine what types of resources are relevant for the client. If the  
purpose is to limit bandwidth (which is likely if e.g. images are turned  
off), rejecting the incoming pushed content is pointless, as most  
resources are less than 64K and thus fully on the wire already, with  
default SPDY initial window. Some sort of actually working Accept-header  
system could be one way to go.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: Mike Belshe <[email-masked]>
Date: Mon, 30 Jul 2012 21:39:08 -0700

On Sun, Jul 29, 2012 at 4:58 PM, Martin Nilsson <[email-masked]> wrote:

> would be different than from a normal request (e.g. for the duration of the
> connection). This is obviously outside of the scope of HTTP semantics, but
> it would be nice if the infrastructure was in place on a binary level (e.g.
> current SPDY/3 can be twisted to support it).
>

I agree this could be useful :-)  But this isn't what SPDY's push does
right now, and that is what I was commenting on.

> on-demand-plugins there are very few relevant resources the server can push
> (frame documents and favicons). The issue is for the server to determine
> what types of resources are relevant for the client. If the purpose is to
> limit bandwidth (which is likely if e.g. images are turned off), rejecting
> the incoming pushed content is pointless, as most resources are less than
> 64K and thus fully on the wire already, with default SPDY initial window.
> Some sort of actually working Accept-header system could be one way to go.

Fair enough, you've presented an argument for who doesn't want push.  But
this is a tiny tiny fraction of people.  I would not sacrifice billions of
internet users that do want images and JS for the needs of a very small
few.  The very small few won't be broken by using push - they'll still get
their pages just fine and can RST the streams they don't want.

I think we should build "fast by default".

mike

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 31 Jul 2012 15:45:09 +0200

On Tue, 31 Jul 2012 06:39:08 +0200, Mike Belshe <[email-masked]> wrote:

>
> Fair enough, you've presented an argument for who doesn't want push.   
> But this is a tiny tiny fraction of people.  I would not sacrifice  
> billions of >internet users that do want images and JS for the needs of  
> a very small few.  The very small few won't be broken by using push -  
> they'll still get their >pages just fine and can RST the streams they  
> don't want.

I've presented an argument from one that would like to see push, but think  
the current SPDY implementation is too simplistic. Just having the client  
white list content types for push would go a long way.

> I think we should build "fast by default".

I think we should build "fast for everyone".

/Martin Nilsson