Various protocol and spec feedback, after working with BOSH for a while.
Feedback is by section; sorry for the length.
5. HTTP Overview:
> The HTTP Content-Type header of all client requests SHOULD be "text/xml;
charset=utf-8".
Ignored headers add unnecessary overhead to every request; upstream is often
severely limited. It would be better to prefer omitting this header
entirely when possible. Are there situations where this might cause
problems?
I'd recommend section 5 say that for the purposes of RFC2616 14.18 [1],
servers MAY consider themselves "without a clock that can provide a
reasonable approximation of current time", so, by that rule, the Date header
can be omitted. BOSH packets should never be cached, so this header is just
overhead.
7.2 Session Creation Response:
> 'requests' -- This attribute enables the connection manager to limit the
number of simultaneous requests the client makes (see Overactivity and
Polling Sessions). The RECOMMENDED values are either "2" or one more than
the value of the 'hold' attribute specified in the session request.
This allows the server ro return nonsensical values. If 'hold' is 3 and
'requests' is 1, the client has no reasonable course of action: it needs to
be able to send four simultaneous requests, yet it's only ever allowed to
send one. I'd recommend requiring (not recommending) that 'requests' must
be at least one greater than the value of the 'hold' attribute specified in
the session response. This ensures the client always receives something
usable.
Also, note that it can be useful for the server to provide a larger value
than hold+1; it allows the client to send bursts of packets without waiting
for a round-trip, just as using hold > 1 allows the server to do the same,
reducing latency. Of course, this is usually only a good idea when
pipelining, not when in multiple-connection mode.
> The <body/> element SHOULD also include the following attributes
'hold' is only a SHOULD, and client behavior seems unspecified if it's
omitted. If the client doesn't know the server's hold value, things will
break. What should clients do here, and why is the server specifying 'hold'
not a MUST? (There seem to be a lot of SHOULDs on the server side, which
turn into complications for clients.)
> 'hold' ... If the client is not able to use HTTP Pipelining then this
SHOULD be set to "1".
The client doesn't always know whether it can use HTTP pipelining during
session creation, since you'll only find out if a proxy doesn't support it
when the first HTTP response comes back. Currently, if the client wants to
reduce @hold in this case, it has to tear the session down and start over,
so it can renegotiate hold.
Since that's often a pain to implement, and clients aren't required to
(higher hold values do work even without pipelining, after all), I suspect
most pipelining clients will skip this, and simply keep the higher hold
value. To make it easier to use a lower hold value when not pipelining, I'd
suggest allowing requesting a new hold value in any <body> packet. (If
'hold' is renegotiated, then 'requests' needs to be, too.)
> 'wait'
> 'hold'
wait='1' hold='0' doesn't make sense. It should be explicitly required that
if either of these are zero, both must be, so sensible values are always
received.
> If it established a secure connection to the server (as defined in
Initiating a BOSH Session),
Where's the definition this refers to?
> then in the same response the connection manager SHOULD also include the
'secure' attribute set to "true" or "1".
The CM should include the server's certificate chain and FQDN, if any, in
the session creation response. This would allow clients to perform their
own certificate checking. This doesn't decrease the trust level of the BOSH
server, but it allows clients to use their own root CA list (and possibly
revocation lists, if anybody implements that) to decide for themselves if
they trust the end server. It also allows handling self-signed server
certificates, which is currently impossible. This wouldn't replace the
'secure' attribute, which is important for simple clients, and for
"built-in" BOSH servers that don't actually connect to a remote server.
> Example 3. Subsequent response with 'from' and 'secure' attributes
This example contains no 'secure' attribute.
11. Overactivity:
> If during any period the client sends a sequence of new requests equal in
length ...
Is this necessary? Servers can effectively rate-limit clients by throttlign
their responses. That way, rate limiting is enforced by the first
Overactivity rule ("longer than the number..."). This simplifies clients,
because when not in polling mode, they no longer have to pay attention to
the 'polling' attribute at all and don't need to perform any timer-based
throttling.
12. Polling Sessions:
> the connection manager MAY require a client to use polling by setting the
'requests' attribute ... of its Session Creation Response to "1"
This complicates clients by forcing them to support polling. It would be
preferable to prohibit this, so clients that don't need polling don't have
to support it. When is this useful enough to justify the extra client
complexity?
> If the client sends two consecutive empty new requests ...
This paragraph seems intended only for polling sessions ("overactivity"
covers the non-polling case), but it doesn't actually say so. It should say
something like: "if the 'hold' attribute specified by the server is 0, and
...". This paragraph should also include the "and did not include either a
'pause' attribute or a 'type' attribute set to 'terminate'" text.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
--
Glenn Maynard
