Re: JSON headers

["Poul-Henning Kamp" <[e-mail]>]

--------
In message <[e-mail]>, "Roy T. Fielding" w
rites:

>> It prevents streaming processing of headers, since you never know
>> when you have the full picture for a particular header, until you've
>> received them all and seen that there are no more instances.
>
>Which is the nature of header fields in general, since we don't know if
>a spoofing attempt is being made until we read all of the headers,
>including the ones not defined as a list.  In any case, we can certainly
>process them as a stream as long as we remember what has already been
>processed so that an appropriate action can be taken for duplicates.

There is a difference between "possible" and "allowed".

>The reason duplicate header fields exist is because email wanted them [...]

And that was probably a worthwhile concern back then.

Today email protocols should have no influence on the _future_ of HTTP.

>The semantics we defined for HTTP/1 allow for new field values to be
>processed and forwarded by a recipient without knowing its definition.

That will still hold true with my proposal, with the footnote that
we do not expect intermediaries to add (copies) of headers they do
not understand the semantics of.

>This is used in practice today by high-speed message forwarding with
>zero-copy constraints to append certain fields at the end of each
>header block.

None of which soundes like an obvious candidate for new structured
format headers to me ?

>In any case, this discussion has nothing to do with Julian's proposal, which
>is to define a common field syntax for HTTP/1.x field values that for some
>insane reason want to use JSON for field processing.

I think you must have misunderstood my proposal if you think so.

My proposal is that once we're done, the RFC should contain these
three parts.

	A) Here is how to put structured data into new HTTP headers
	   (Be it JSON or something saner).

		1) HTTP/1

		2) HTTP/2

	B) A header using this format can only appear at most once
	   in any HTTP message.  Split or repeat headers *using
	   this format* are not allowed.

	C) Here is how you write up a specification for such a header
	   in an RFC.  (ABNF/Schema/something)

That does not change the semantics of any currently defined
headers, nor of any headers not using the new format - JSON or
otherwise.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.