RE: #305 Header ordering

I'm OK with this.

For HPACK, this means that we need to remove the ordering requirements for emission. Add we should probably add that header values should not be split at the compaction layer.

Hervé.

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: mardi 26 novembre 2013 03:19
> To: Jeff Pinner
> Cc: Martin Thomson; Roberto Peon; Tatsuhiro Tsujikawa; RUELLAN Herve;
> Amos Jeffries; ietf-http-wg@w3.org
> Subject: Re: #305 Header ordering
> 
> Given that this is holding up the implementation draft and we have running
> code for #1, let's stick with it for now. If people feel strongly, we can revisit in
> the next round.
> 
> Make sense?
> 
> Cheers,
> 
> 
> On 25/11/2013, at 5:39 PM, Jeff Pinner <jpinner@twitter.com> wrote:
> 
> > My $.02,
> >
> > We've seen '\0' delineation work well and I'm not sure what we gain by
> changing it to ','
> >
> > If an intermediary is going to fold multiple headers because it isn't sure that
> order is important (especially for headers that do not allow commas) then I
> would prefer to be able to reconstruct the original as faithfully as possible. For
> example, let's suppose I get a request with multiple host or content-length
> headers (yes this does occur). If an intermediary concatenates them, I would
> prefer it be in a way that lets me re-construct the original input.
> >
> > - Jeff
> >
> >
> >
> >
> > On Sat, Nov 23, 2013 at 1:47 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 23 November 2013 13:33, Roberto Peon <grmocg@gmail.com> wrote:
> > > Wouldn't it be the higher-layers only that need to parse
> > > quoted-strings today?  Many loadbalancers need-not parse
> > > quoted-strings today, for
> > > instance: it is unlikely that any field they care about examining
> > > allows quoted-strings...
> > >
> > > At least in my implementation, the data within the header fields
> > > (which might include quoted-strings) are provided by the application
> > > which manipluates a headers object. The headers object or lower
> > > never needs to parse the field in the outbound path.
> > > On the reverse side, the IO library+framer feeds the keys/values
> > > into a header object. It doesn't tokenize-- that is left to the
> > > application. The framer/headers object never needs to parse the fields in
> the inbound path.
> >
> > That's all true, and exactly the point.
> >
> > > Setting that point aside, how would I deal with the following
> > > response headers in the #3 proposal?
> > >   Set-Cookie: name1=value1; Expires=Wed, 09 Jun 2021 10:18:14
> > >   Set-Cookie: name2=value2; Expires=Thu, 10 Jun 2021 10:18:14
> > >   Set-Cookie: name3=value3; Expires=Fri, 11 Jun 2021 10:18:14
> >
> > I don't know why we keep coming back to the special cases.  But
> > anyway, as proposed, we understand order to not be significant for
> > Set-Cookie, so this would manifest as multiple name-value pairs, in a
> > non-deterministic order.  Cookie is special too, but we actually need
> > new rules for Cookie.
> >
> > Set-Cookie breaks the general grammar rules for header fields and
> > needs to be treated specially.  Neither proposal changes that
> > characteristic.
> >
> > > Much of the time, there isn't a good reason to want to send these as
> > > separate header fields.
> >
> > For Set-Cookie, sure, but in terms of cost, it's a question of a few
> > bytes difference at most.  I'm not going to get cut up about that.
> >
> >
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
>

Received on Tuesday, 26 November 2013 16:42:41 UTC