Re: PING frame behavior

On Sat, Apr 19, 2014 at 7:50 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014–04–20, at 5:55 AM, Alek Storm <alek.storm@gmail.com> wrote:
>
> > 1. Are PING frame receivers obligated to respond with PING+ACK?
> > 2. Must the PING+ACK payload be identical to that of the original PING?
>
> From the spec: “Receivers of a PING frame that does not include an ACK
> flag MUST send a PING frame with the ACK flag set in response, with an
> identical payload.”
>

Oh, wow. I cannot believe I missed that when reading the spec. Thanks for
the correction!

If you don’t want a reply but only side-band communication, you may send a
> PING with ACK pre-set. The spec defines behavior for this case and does not
> mention a protocol violation.
>
> > 3. May the sender generate additional PING frames before the first is
> ACK’d?
>
> Why not? There’s no state. Also, the other end can’t reliably tell the
> difference.
>

Good point. I suppose the amount of resources an endpoint has to commit to
answering a PING frame is trivial.

> 4. May intermediaries forward PING frames?
>
> Where would they get forwarded? End-to-end would be nice, but without a
> stream ID you can usually only go one hop. The spec leaves a little
> ambiguity, which seems OK to me.
>
> Come to think of it, was end-to-end, stream-wise PING considered and
> rejected for a particular reason? I guess it would tend to flood origin
> servers that are usually cached, so that’s a major vulnerability.
>

My thoughts exactly, with the exception that clearer language prohibiting
PING forwarding would be nice.

Thanks,
Alek