Subject: [hybi] short term requirements

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Oct 2009 19:15:03 +0300

Hi there,

as you may have read on the Agenda draft,
during the BoF meeting we will discuss, among other stuff, requirements 
for Short Term solution.

This is a call to collect requirements that you think a Short Term 
solution should meet.

Draft-loreto-http-bidirectional 
(http://www.ietf.org/id/draft-loreto-http-bidirectional-00.txt)
is a tentative to describe best practices for bidirectional HTTP in the 
context of HTTP as it exists today.
In order to design additions (section 6 of the draft to see some 
example) that could enable improved mechanisms
for bidirectional HTTP  (short term solution) we have to identify the 
requirements that those additions have to meet
in order to improve interoperability and such to provide an improved 
experience.

Here a first rough list of requirements collected from the bar BoF in 
Stockholm and from the HyBi mail discussion.
It is just a list to start the discussion

Req.   possibility for the intermediaries to access and modify it
Req.   it must be usable from multiple (existing) browser
Req.   it must be easily to use and accessible from different protocols 
(e.g. Bayeux, Bosh etc)
Req.   it must be easy to deploy in the existing infrastructure
Req.   it has really improve the bi-directional communication (not just 
push from a server to a client)
Req.   it has not introduce any security hole

please provide comments, opinions, suggestion.

best regards
Salvatore Loreto

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 17 Oct 2009 21:58:02 -0700

> please provide comments, opinions, suggestion.

I would like to add

Req.   That there must be a standard way to indicate that a HTTP request is
       being used for bidirectional purposes, preferably distinguishing
       streaming and long polling uses.

This will allow HTTP implementations to avoid pitfalls such as pipelining behind
long polls, and to warn if limited thread pools are exhausted by long held requests.

I also think there needs to be something about improving cross domain, or
RBPs for using optional XD mechanisms and well used hacks.

regards

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 18 Oct 2009 05:59:43 +0100

> push from a server to a client)

Among the talk about multiplexing and/or spawning parallel connection,
one valuable thing that's not mentioned enough: learn from the
mistakes of HTTP pipelining.  Don't repeat them.  There's no point in
protocol features that can't be used because of design flaws.

Specifically, real clients *can't* use pipelining in a lot of
situations because it's either unsafe (can't be used for POST, or
anything that's not idempotent; messy idle timeout uncertainties;
messy behaviour on network errors), or can make performance a lot
worse (fast response delayed by a slow one; second response dropped
because first response had an error during generation so connection
had to be closed), or is just plain buggy (due to being added to the
HTTP spec and tested too long after servers existed which couldn't
handle it).

All the protocols under consideration resemble HTTP pipelining in some
respects.  WebSockets has all of those problems for some applications,
and requires the application layer to solve them.  Imho, expect mixed
results depending on application developer experience.  BWTP attempts
to solve them; I haven't looked into how well it succeeds.

A protocol which gives the benefits of HTTP pipelining for
client-originated requests without the known problems would be an
improvment, even for applications which aren't pushing from the server.

Notable, AJAX frameworks could use such a protocol in a way that is
invisible to users of those frameworks, and AJAX frameworks are
extremely popular in current web apps.

I don't know if that's a short term requirement but it's worth
examining.  It might turn out to be the most widespread use.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 18 Oct 2009 06:03:07 +0100

Greg Wilkins wrote:
> This will allow HTTP implementations to avoid pitfalls such as
> pipelining behind long polls, and to warn if limited thread pools
> are exhausted by long held requests.

I agree with Greg, and would like to add that I'm not sure if
"Connection: close" is adequate for that purpose.  It's not as
descriptive, but is it (a) enough for all existing proxies and servers
to behave well; (b) is something more specific to streaming and long
polling useful?

-- Jamie

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 23 Oct 2009 17:29:11 +0300

Hi there,

see my answers below !

cheers
Sal

Greg Wilkins wrote:
> regard

[Sal] good you mentioned it. There has been some discussion both in the 
mailing list and in the Bar BoF.
I remember that one possible solution mentioned in the ml and in the BoF 
was to use a sort or the time-out header
in the request that will indicate that the answer to that request could 
be delayed until the time-out value expires.

> to behave well; (b) is something more specific to streaming and long
[Sal] of course, we can mandate "Connection: close", but it would be 
better have something more specific
and useful. Maybe time-out header is not so useful for streaming 
mechanism and we need something else
for improve the streaming.
In any case this in the realm of solution.
Lets before all agree on the requirements.