Re: #557 Intra-Message HEADERS frames was: Striving for Compromise (Consensus?)

I'd tend to agree that re-using HEADERS for intra-DATA is possibly
confusing, but there will likely be use-cases.  (There was a thread that
discussed this around two months or so ago --- it gets more interesting for
when the END_* flags come into play.)

As for "semantic" mapping to HTTP/1.1, chunked encoding extensions are the
best match.  ICAP has one defined, and I'm aware of at least one
proprietary chunked encoding extension used for hop-by-hop data integrity.


On Sat, Jul 12, 2014 at 5:35 PM, <K.Morgan@iaea.org> wrote:

> https://github.com/http2/http2-spec/issues/557
>
> On 12 Jul 2014, at 23:29, "MORGAN, Keith Shearl" <K.Morgan@iaea.org>
> wrote:
> >
> > On 11 Jul 2014, at 15:22, "jpinner@twitter.com" <jpinner@twitter.com>
> wrote:
> >
> >> It
> >> also prevents experimenting with the type of inter-message HEADERS
> >> frames that some people wanted (streaming checksums and the like) that
> >> are currently permitted to be sent but have no "semantic" mapping to
> >> HTTP/1.1
> >
> > I'm all for this, but I've said this before, and I'll say it again.
> Re-using HEADERS frames for this purpose is confusing. Are they hpack
> encoded? What does it mean if you get an intra-message HEADERS frame and
> END_HEADERS is set? Is END_STREAM allowed?
> >
> > Why not just add a simple METADATA frame and be done with it?
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>
>