- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 15 Jan 2013 19:05:36 -0600
- To: Nico Williams <nico@cryptonector.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Karl Dubost <karld@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Piotr Dobrogost <p@ietf.dobrogost.net>, ietf-http-wg@w3.org
On Tue, Jan 15, 2013 at 5:22 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Jan 15, 2013 at 4:09 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> Saying that headers can only be combined under certain circumstances doesn't mean that they're required to be combined.
>
> It might help to be able to say that all new headers must be
> mergeable. That is: how can a proxy or what have you, know whether
> it's OK to merge a given header's multiple instances? And I think the
> answer is as Poul said: you should never do it. But then shouldn't we
> say so?
>
> Whatever was the point of this feature in the first place? Was it a
Ideally no header should be repeated - it adds another layer of
structure that needs to be explained.
RFC 822 seems to allow, but discourage multiple headers of the same name
4.1.
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
RFC 2616 probably wanted to clarify the meaning of multiple
occurrences, instead of leaving them undefined.
> form of header compression? If so, isn't it best to stop merging
> multiple instances of headers and just go with whatever header
> compression scheme we settle on?
>
> Nico
> --
>
Received on Wednesday, 16 January 2013 01:06:03 UTC