Re: Question about H2 and chunked encoding

On Wed, Sep 27, 2017 at 12:29:57PM -0700, Roy T. Fielding wrote:
> > In fact I think the root cause of this permanent difficulty is that we
> > all know that some header fields are used to influence message parsing
> > and framing while others are related to content definition, which used
> > to be called entity-header fields in 2616. But by considering all of
> > them as header fields without a strict distinction, we're seeing some
> > exceptions like above appear.
> 
> Well, no, the root cause is that there is no syntactic distinction between
> various types of header fields that could be easily seen by all recipients.
> That's how we make a protocol self-descriptive.

I totally agree that it would have been much easier that way but that's not
what we have *for now*.

> The problem is that we have no choice in "considering all of them as header
> fields without a strict distinction".  That's HTTP/1.  It isn't going to
> change by adding requirements to a spec that simply aren't true for HTTP/1.
> Even if we required a prefix on names, we'd still have to deal with the
> folks who don't read specifications and either fail to use the prefix or
> copy the wrong prefix from somewhere else.

In fact HTTP/1 probably isn't going to evolve much on the framing side, at
least by lack of incentive from those who used to push it as far as possible
for performance reasons. It seems to me it would be reasonable to draw this
list for H1 and find other mechanisms for H2+. For example, in H2, the use
of ":status" etc could seem strange at first but actually is a good solution
to split those critical header fields and the other ones. It's just one
solution, but I think we should not declare that it's too late just because
the protocols are already in the wild. What's deployed works with what it
does now, we can try to find ways to improve how we'll proceed in the future.

> > I tend to think that the wording in 7230
> > using "e.g." in the list is exactly what makes it hard for implementations
> > to establish a strict list, and that it might be useful to draw such a
> > list of the fields affecting message parsing and framing, those affecting
> > message routing/acceptance (host,cookie/set-cookie,auth,cache-control,...)
> > and maybe other classes, and establish a matrix of which ones are allowed
> > where.
> 
> But, there is no strict list.  That's the point of the e.g.'s.  We can't add
> requirements that have no basis in the protocol practice.  I think it is a
> fine idea to make distinctions clearer in the registry, but that doesn't
> change the normative requirements (how to interoperate).  A strict list is
> not going to be interoperable after deployment.

I don't necessarily agree here, it depends if we have a version to help
make the distinction. For instance, while HTTP/1.0 vs 1.1 was a pain to
deal with regarding persistent connections due to 1.1 mostly being emitted
to try to normalize what people were already doing, it still managed to
work. I agree however that fixing too hard limits is not future proof
and that at least one dimension must be allowed to change when the other
ones are fixed.

> > For example for H2 we have a strict list of the fields that must be
> > discarded during H1 to H2 translation, that makes it easier to implement.
> 
> *sigh*

I mean it's easier to implement than having to implement "e.g.". This
implementation is tied to this version and is not allowed to evolve for
that version. That's the limitation.

Cheers,
Willy

Received on Thursday, 28 September 2017 22:13:50 UTC