If not JSON, what then ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Mark Nottingham-2

> On 2 Aug 2016, at 1:53 PM, Willy Tarreau <[hidden email]> wrote:
>
> Hi Mark,
>
> On Tue, Aug 02, 2016 at 01:33:39PM +0200, Mark Nottingham wrote:
>> 1) Using the first character of the field-value as a signal that the encoding
>> is in use is interesting. I was thinking of indicating it with a suffix on
>> the header field name (e.g., Date-J). Either is viable, but I don't think
>> it's a good idea to reuse existing header field names and rely on that signal
>> to differentiate the value type; that seems like it would cause a lot of
>> interop problems to me. Defining a new header field (whether it's Date-J or
>> Date2 or whatever) seems much safer to me.
>
> I had the same feeling initially but I retracted. I fear that having two
> header fields will result in inconsistencies between the two (possibly
> intentional when that may be used to benefit an attacker). We'd rather
> avoid reproducing the Proxy-Connection vs Connection mess we've been seeing
> for a decade, where both were sent "just in case".

I know, I don't like it either. I'm just concerned that if we keep the name the same, it's much more likely it's going to not be properly converted, and that could enable attacks too.

Stepping back, I think we're talking about a set of rules something like this;

A. For a newly defined header field that explicitly uses the new format, send it in the new format
B. For existing header fields, if their expression in the new format is defined:
  1. If you have evidence that your peer can accept the new header format, send them in the new format
  2. Otherwise, send them in the original format.
C. All other fields are always sent in the original, HTTP/1 format.

I.e., having both versions of a single header's semantics the wire at the same time is an error.

This means that the format of those headers is effectively a hop-by-hop attribute; you might have a situation where a non-format-aware node forces the hops surrounding it back to the original format (for headers with two different ways to express those semantics).

This gives me pause. Converting from new to old and back to new is very likely to tickle a lot of bugs and cause a lot of interop problems. So, we could say that conversion only happens as a downgrade; i.e., if the next hop doesn't support the encoding, you can downgrade, but you never upgrade it again to the new encoding.

Presumably, the last "hop" might be inside the origin server, when it converts those header fields into the old format for backwards compatibility with existing applications that aren't aware of the new format.

Applications that *are* aware of the new format will still need to handle the original format, because there will be clients / hops generating it for the foreseeable future.

This kind of seems like a mess to me, and leads me to think that the only time we should attempt this is during a major protocol revision (i.e., h3), and even then, with great trepidation.

If we get that far, deciding how to signal which headers are encoded seems more manageable :)


> However if we enumerate certain header fields that would deserve being
> encoded differently and find a way to group them, we may think about
> sending a composite, compact header field for transport/routing, another
> one for the entity where available information are grouped when relevant.
> Then maybe it could be decided that when one agent consumes such a field,
> before passing the message it must delete occurences of the other ones,
> and/or rebuild them from the composite one, in order to avoid inconsistency
> issues.
>
> We have more or less this regarding Transfer-Encoding which voids
> Content-Length, and the Host header field which must always match the
> authority part of the URI if present.
>
> These are just thoughts, maybe they are stupid.

Not stupid at all, but I am concerned about adding too much "magic"; if implementations are doing too much on your behalf, issues will arise (see above).

Cheers,



--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
In reply to this post by Nicolas Mailhot
--------
In message <[hidden email]>, nicol
[hidden email] writes:

>I thouroughly mislike all the encoding dance and escaping one time
>it's UTF-8 another not.

I think you are barking up another tree than I am.

I'm trying to find a way to lay down a common structure so people
dont *have* to break things to get them to work as they do now.

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

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Mark Nottingham-2
In reply to this post by Poul-Henning Kamp

> On 2 Aug 2016, at 2:01 PM, Poul-Henning Kamp <[hidden email]> wrote:
>
> --------
> In message <[hidden email]>, Mark Nottingham wri
> tes:
>
>> A few thoughts come to mind:
>>
>> 1) Using the first character of the field-value as a signal that the
>> encoding is in use is interesting. I was thinking of indicating it with
>> a suffix on the header field name (e.g., Date-J).
>
> Yeah, that could work too, but I suspect it would be more cumbersome
> to implement, and it creates a new class of mistakes which need to
> be detected  - "Both Date and Date-J ??"

See separate discussion.

>
>> 2) Regardless of #1, using < as your indicator character is going to
>> collide with the existing syntax of the Link header.
>
> If Link is "<> blacklisted" in the IANA registry, that wouldn't be a
> problem, and all currently defined headers will need to be checked
> against some kind of white/black list, if we want them to use the
> new "common structure".
>
> I picked <> because they were a cheap balanced pair in HPACK/huffman
> and I only found Link that might cause a false positive.
>
> Strictly speaking, it doesn't have to be a balanced pair, it could
> even be control-characters but HPACK/huffman punish those hard.
>
> I didn't dare pick () even though it had even shorter HPACK/huffman.
>
> Thinking about it now, I can't recall any headers starting with a '('
> so () might be better than <> and thus avoid the special case of Link.

That might work.

>
>> 3) I really, really wonder whether we need recursion beyond one level;
>
> As do I.
>
> However, if it is recursion, the implementation cost is very low,
> and I would prefer to "deliver tools, not policy" and let people
> recurse until they hurt if they want.
>
> I particular do not want to impose complexity limits on private
> headers, based on the simplicity of public headers, because my
> experience is that private headers are more complex.
>
> I would prefer a simple, general model, restricted by machine
> readable schemas, rather than a complex model with built in
> limitations.

Nod.

Right now, most implementations limit header field values on length; if they start limiting on recursion as well, it would be good to have a reasonable value specified (or at least suggested).


>> 4) I agree with the sentiment that non-ascii strings in header field
>> values are comparatively rare (since most headers are not intended for
>> display), so while we should accommodate them, they shouldn't be the
>> default.
>
> That was the idea behind: \U  Make people explicitly tag UTF8

Ok.

>> 5) I like the idea of 'implicit angle brackets' to retrofit some
>> existing headers. Depending on the parse algorithm we define, we could
>> potentially fit a fair number of existing headers into this, although
>> deriving the specific data types of things like parameter arguments is
>> going to be difficult (or maybe impossible). Needs some investigation
>> before we know whether this would be viable.
>
> Schemas!  Have I mentioned already how smart I think schemas usable
> to build code with would be ?  :-)

So it's really "implicit angle brackets plus a reference to a retrofitted schema". OK.

Get on another train and start working on that schema language. :)


> PS: I had expected you to ask if was trying to sabotage your Key header :-)

That's one of the reasons I complained about arbitrary recursion.

However, whatever happens here, I think we have to accept that Key will not be able to address all header fields; it's always going to be a subset. If a particular header field wants to leverage Key, it'll need to be specified within its capabilities (provided it gets traction, of course).

Cheers,


--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Willy Tarreau-3
In reply to this post by Mark Nottingham-2
On Tue, Aug 02, 2016 at 02:41:19PM +0200, Mark Nottingham wrote:
> Not stupid at all, but I am concerned about adding too much "magic"; if
> implementations are doing too much on your behalf, issues will arise (see
> above).

You probably know that I hate magic as well, that's why I prefer to rely
on what we have. For example, passing "connection:" with the new headers
to optimize their eviction along non-compatible paths is doable. It's not
100% safe but doable. Ensuring that compatible actors replace the old
version is doable as well because it would be a "MUST" in the spec and we
know these actors don't exist yet. So all in all we can possibly do useful
things. I just don't want to have a tens of headers being advertised in
Connection nor having to add many extra headers for the sake of saving
space and parsing time, because we know that it will add extra work that
may sometimes offset the savings. Hence the idea to compact what can be
compacted if we went down that route.

Cheers,
Willy

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Mark Nottingham-2
Unfortunately, implementation of the Connection header was really, really bad. :-/


> On 2 Aug 2016, at 2:55 PM, Willy Tarreau <[hidden email]> wrote:
>
> On Tue, Aug 02, 2016 at 02:41:19PM +0200, Mark Nottingham wrote:
>> Not stupid at all, but I am concerned about adding too much "magic"; if
>> implementations are doing too much on your behalf, issues will arise (see
>> above).
>
> You probably know that I hate magic as well, that's why I prefer to rely
> on what we have. For example, passing "connection:" with the new headers
> to optimize their eviction along non-compatible paths is doable. It's not
> 100% safe but doable. Ensuring that compatible actors replace the old
> version is doable as well because it would be a "MUST" in the spec and we
> know these actors don't exist yet. So all in all we can possibly do useful
> things. I just don't want to have a tens of headers being advertised in
> Connection nor having to add many extra headers for the sake of saving
> space and parsing time, because we know that it will add extra work that
> may sometimes offset the savings. Hence the idea to compact what can be
> compacted if we went down that route.
>
> Cheers,
> Willy

--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
In reply to this post by Mark Nottingham-2
--------
In message <[hidden email]>, Mark Nottingham wri
tes:

>Stepping back, I think we're talking about a set of rules something like
>this;

>A. For a newly defined header field that explicitly uses the new format,
>   send it in the new format
>B. For existing header fields, if their expression in the new format is
>   defined:
>  1. If you have evidence that your peer can accept the new header
>     format, send them in the new format
>  2. Otherwise, send them in the original format.
>C. All other fields are always sent in the original, HTTP/1 format.

Yes, something like that.

However, this is digging deep into the extreme far end of the ideas
I presented, and it seems rather too speculative to dig much further.

I am far more interested in hearing what people think about the
important part of the write-up:  Deriving and generalizing a
common header structure from existing HTTP1 header syntaxes ?

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

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Mark Nottingham-2

> On 2 Aug 2016, at 3:06 PM, Poul-Henning Kamp <[hidden email]> wrote:
>
> --------
> In message <[hidden email]>, Mark Nottingham wri
> tes:
>
>> Stepping back, I think we're talking about a set of rules something like
>> this;
>
>> A. For a newly defined header field that explicitly uses the new format,
>>  send it in the new format
>> B. For existing header fields, if their expression in the new format is
>>  defined:
>> 1. If you have evidence that your peer can accept the new header
>>    format, send them in the new format
>> 2. Otherwise, send them in the original format.
>> C. All other fields are always sent in the original, HTTP/1 format.
>
> Yes, something like that.
>
> However, this is digging deep into the extreme far end of the ideas
> I presented, and it seems rather too speculative to dig much further.
>
> I am far more interested in hearing what people think about the
> important part of the write-up:  Deriving and generalizing a
> common header structure from existing HTTP1 header syntaxes ?

I think that's the way to go, and that using it for *newly defined* headers is a good enough use case.

If we can pause discussion of porting existing headers to the new format for the time being, it may help.

Cheers,


--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
In reply to this post by Mark Nottingham-2
--------
In message <[hidden email]>, Mark Nottingham wri
tes:

>>> 5) I like the idea of 'implicit angle brackets' to retrofit some
>>> existing headers. Depending on the parse algorithm we define, we could
>>> potentially fit a fair number of existing headers into this, although
>>> deriving the specific data types of things like parameter arguments is
>>> going to be difficult (or maybe impossible). Needs some investigation
>>> before we know whether this would be viable.
>>
>> Schemas!  Have I mentioned already how smart I think schemas usable
>> to build code with would be ?  :-)
>
>So it's really "implicit angle brackets plus a reference to a
>retrofitted schema". OK.

yes.

>Get on another train and start working on that schema language. :)

I should have seen that one coming :-)

>> PS: I had expected you to ask if was trying to sabotage your Key
>header :-)
>
>That's one of the reasons I complained about arbitrary recursion.
>
>However, whatever happens here, I think we have to accept that Key will
>not be able to address all header fields; it's always going to be a
>subset. If a particular header field wants to leverage Key, it'll need
>to be specified within its capabilities (provided it gets traction, of
>course).

The interesting angle is that if we have such a common structure, the
Key header could use it to describe exactly what you want to pull out
of a header, not as a substring, but as correctly parsed data elements.


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

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Nicolas Mailhot
In reply to this post by Poul-Henning Kamp


----- Mail original -----
De: "Poul-Henning Kamp" <[hidden email]>


>>I thouroughly mislike all the encoding dance and escaping one time
>>it's UTF-8 another not.

>I think you are barking up another tree than I am.

>I'm trying to find a way to lay down a common structure so people
>dont *have* to break things to get them to work as they do now.

I appreciate the intent (really) but I feel the result of tip-toeing around unicode rules just generates a lot of complexity, makes the general case complex and special cases simple, when it should be the reverse (general case → just UTF-8 with no additional rules, special cases → just use binary)

There are 7 (!) text encoding cases in your proposal

--
Nicolas Mailhot

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Willy Tarreau-3
In reply to this post by Mark Nottingham-2
On Tue, Aug 02, 2016 at 03:08:37PM +0200, Mark Nottingham wrote:

>
> > On 2 Aug 2016, at 3:06 PM, Poul-Henning Kamp <[hidden email]> wrote:
> >
> > --------
> > In message <[hidden email]>, Mark Nottingham wri
> > tes:
> >
> >> Stepping back, I think we're talking about a set of rules something like
> >> this;
> >
> >> A. For a newly defined header field that explicitly uses the new format,
> >>  send it in the new format
> >> B. For existing header fields, if their expression in the new format is
> >>  defined:
> >> 1. If you have evidence that your peer can accept the new header
> >>    format, send them in the new format
> >> 2. Otherwise, send them in the original format.
> >> C. All other fields are always sent in the original, HTTP/1 format.
> >
> > Yes, something like that.
> >
> > However, this is digging deep into the extreme far end of the ideas
> > I presented, and it seems rather too speculative to dig much further.
> >
> > I am far more interested in hearing what people think about the
> > important part of the write-up:  Deriving and generalizing a
> > common header structure from existing HTTP1 header syntaxes ?
>
> I think that's the way to go, and that using it for *newly defined* headers
> is a good enough use case.

Same here.

> If we can pause discussion of porting existing headers to the new format for
> the time being, it may help.

Very likely but we all know it's very tempting at the same time. They
also serve as good examples of what we may need in the future.

Willy

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Carsten Bormann
In reply to this post by Poul-Henning Kamp
I don't know when Poul-Henning will catch a train the next time...

But I was interested in whether CDDL can be used as a specification
language here, because it is always good to look at more use cases.
So let's see (mostly untested at this point because I have no idea
whether anybody wants to use CDDL in this context, but examples should
work with the CDDL tool today):

> Schemas
> =======
>
> There needs a "ABNF"-parallel to specify what is mandatory and
> allowed for these headers in "common structure".

Indeed, CDDL is essentially ABNF ported to tree grammars.

The top-level data model of the proposed format could be expressed as:

header-value = [* dict-element]
dict-element = [name, value-map]
name = text                          ; possibly restricted
value-map = {* name => value}        ; empty by default
value = text / bytes / number / time / value-map
                                     ; add as needed

> Ideally this should be in machine-readable format, so that
> validation tools and parser-code can be produced without
> (too much) human intervation.  I'm tempted to say we should
> make the schemas JSON, but then we need to write JSON schemas
> for our schemas :-/

For -09, we are discussing to add a separate machine-readable (JSON)
encoding to be used by tools, in addition to the human-readable format
to be used by humans.  (No intention to make both the same, that would
be a classical mistake.)

> Since schemas basically restict what you are allowed to
> express, we need to examine and think about what restrictions
> we want to be able to impose, before we design the schema.
>
> This is the least thought about part of this document, since
> the train is now in Lund:

OK, let's see what restrictions CDDL offers today (they are called
"annotations" there, a not so bright name to be changed):

> Unicode strings:
> ----------------
>
> * Limit by (UTF-8) encoded length.
> Ie: a resource restriction, not a typographical restriction.

That would be .size:

dns-label = text .size (1..63)

> * Limit by codepoints
> Example: Allow only "0-9" and "a-f"
> The specification of code-points should be list of codepoint
> ranges.  (Ascii strings could be defined this way)

Today this is generally done via regexps.

> * Limit by allowed strings
> ie: Allow only "North", "South", "East" and "West"

Those are typically done constructively:

direction = "North" / "South" / "East" / "West"

Of course, regexps can do that, too, if needed.

> Tokens
> ------
>
> * Limit by codepoints
> Example: Allow only "A-Z"

token1 = text .regexp "[A-Z]"

> * Limit by length
> Example: Max 7 characters

CDDL can only count characters (as opposed to bytes) employing regexps
right now.
Another extension may be needed if there indeed is a good use case for
counting characters.

> * Limit by pattern
> Example: "A-Z" "a-z" "-" "0-9" "0-9"
> (use ABNF to specify ?)

(Regexps, again)

> * Limit by well known set
> Example: Token must be ISO3166-1 country code
> Example: Token must be in IANA FooBar registry

Interesting.  There currently is no formal interface to IANA (or ISO)
registries; we don't have an informal escape like ABNF has in prose-val.
"Annotations" could be added as needed and they are close.

> Qualified Tokens
> ----------------
>
> * Limit each of the two component tokens as above.
>
> Binary Blob
> -----------
>
> * Limit by length in bytes
> Example: 128 bytes
> Example: 16-64 or 80 bytes

blob1 = bytes .size (16..64 / 80)

> Number
> ------
>
> * Limit resolution
> Example: exactly 3 decimal digits

Would need a new CDDL "annotation", say

q = number .decimals 3

> * Limit range
> Example: [2.716 ... 3.1415]

etopi = 2.718..3.1415

> Integer
> -------
>
> * Limit range
> Example [0 ... 65535]

ex1 = 0..65535
ex2 = uint .size 2

> Timestamp
> ---------
>
> (I cant thing of usable restrictions here)

ts = uint   ; (or whatever type of timestamp you want;
            ;  `time` as a POSIX time and RFC3339 dates are built in)

Grüße, Carsten

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
--------
In message <[hidden email]>, Carsten Bormann writes:

>But I was interested in whether CDDL can be used as a specification
>language here,

I'm guess it is this draft ?

   https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/

>For -09, we are discussing to add a separate machine-readable (JSON)
>encoding to be used by tools, in addition to the human-readable format
>to be used by humans.  (No intention to make both the same, that would
>be a classical mistake.)

I don't have an informed opinion about CDDL at this point, but
having two parallel specifications sounds like a clas^H^H^H^Hantiquity
mistake to me.

How do you plan to make sure they both say the same thing ?

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

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Carsten Bormann
Poul-Henning Kamp wrote:
> I don't have an informed opinion about CDDL at this point, but
> having two parallel specifications sounds like a clas^H^H^H^Hantiquity
> mistake to me.
>
> How do you plan to make sure they both say the same thing ?

You generate the JSON one from the original CDDL source when you need it.
(The JSON version is for interchange between tools working on instances
of the specification language, not for humans to work on it.  Of course
it is not hard to write a CDDL parser, but it is even easier to ingest
JSON from an existing CDDL parser, and standardizing this intermediate
format together with the language sounds like a good idea and is simple
enough to do.)

Grüße, Carsten

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Mark Nottingham-2
If containers are only allowed to contain simple types, the need for a schema language diminishes quite a bit; headers can be defined pretty easily in prose, perhaps with references to registries where appropriate.

Personally, the discussion below makes me think that's a good thing...


> On 2 Aug 2016, at 9:46 PM, Carsten Bormann <[hidden email]> wrote:
>
> Poul-Henning Kamp wrote:
>> I don't have an informed opinion about CDDL at this point, but
>> having two parallel specifications sounds like a clas^H^H^H^Hantiquity
>> mistake to me.
>>
>> How do you plan to make sure they both say the same thing ?
>
> You generate the JSON one from the original CDDL source when you need it.
> (The JSON version is for interchange between tools working on instances
> of the specification language, not for humans to work on it.  Of course
> it is not hard to write a CDDL parser, but it is even easier to ingest
> JSON from an existing CDDL parser, and standardizing this intermediate
> format together with the language sounds like a good idea and is simple
> enough to do.)
>
> Grüße, Carsten
>

--
Mark Nottingham   https://www.mnot.net/





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
--------
In message <[hidden email]>, Mark Nottingham wri
tes:

>If containers are only allowed to contain simple types, the need for a
>schema language diminishes quite a bit; headers can be defined pretty
>easily in prose, perhaps with references to registries where
>appropriate.

It is not significantly harder to specify recursive structures than
flat structures, but of course the work to do so will make many
people want not to.

As for the praise for prose, yes, it is amazing what you can do if
you are Hemmingway, Prachett, Jefferson or Adams, but most of us
are not.

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

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Carsten Bormann
In reply to this post by Mark Nottingham-2
Mark Nottingham wrote:
> If containers are only allowed to contain simple types, the need for a schema language diminishes quite a bit; headers can be defined pretty easily in prose, perhaps with references to registries where appropriate.

The same observation could be made of textual information and ABNF.
In the last 40 years, the industry has converged on using BNF in
specifications of languages as a matter of routine for a number of good
reasons; these become even stronger with a standard notation such as
ABNF which allows throwing some tooling into the specification process
without losing the benefit of a human-readable notation.
Yes, I have run into people who see little value in adding ABNF to
specifications; the benefit may not be universal for all users of a
specification.

I expect the same kind of benefits from using CDDL for JSON-like data
models.  (We had a similar discussion for COSE, which is very simple as
a data model, too*); still the CDDL snippets do help many spec readers,
and the tooling also does help in validating the examples against the spec.)

Grüße, Carsten

*) Well, OK, it *does* have recursion in the recipients in the
encryption spec.

(Pet peeve: "Schema languages" fundamentally come from a database world
and try to solve a different problem, even though they may overlap with
tree grammars; but the usage has become sufficiently confused in the
last 20 years that I won't insist on this difference.  But I won't get
caught calling CDDL a "schema language"...)

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Martin Thomson-3
In reply to this post by Poul-Henning Kamp
On 2 August 2016 at 22:01, Poul-Henning Kamp <[hidden email]> wrote:
> Thinking about it now, I can't recall any headers starting with a '('
> so () might be better than <> and thus avoid the special case of Link.


Or ><?

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Kari Hurtta
In reply to this post by Mark Nottingham-2
| 1) Using the first character of the field-value as a signal that the encoding is in use is interesting. I was
| thinking of indicating it with a suffix on the header field name (e.g., Date-J). Either is viable, but I
| don't think it's a good idea to reuse existing header field names and rely on that signal to differentiate
| the value type; that seems like it would cause a lot of interop problems to me. Defining a new header field
| (whether it's Date-J or Date2 or whatever) seems much safer to me.
|
| 2) Regardless of #1, using < as your indicator character is going to collide with the existing syntax of the
| Link header.

Or perhaps use ':' as indicator? Causes double '::' on HTTP/1

Date::1470205476

Is this viable ?

/ Kari Hurtta





Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Willy Tarreau-3
On Wed, Aug 03, 2016 at 09:37:30AM +0300, Kari hurtta wrote:

> | 1) Using the first character of the field-value as a signal that the encoding is in use is interesting. I was
> | thinking of indicating it with a suffix on the header field name (e.g., Date-J). Either is viable, but I
> | don't think it's a good idea to reuse existing header field names and rely on that signal to differentiate
> | the value type; that seems like it would cause a lot of interop problems to me. Defining a new header field
> | (whether it's Date-J or Date2 or whatever) seems much safer to me.
> |
> | 2) Regardless of #1, using < as your indicator character is going to collide with the existing syntax of the
> | Link header.
>
> Or perhaps use ':' as indicator? Causes double '::' on HTTP/1
>
> Date::1470205476
>
> Is this viable ?

It could but strictly speaking it will not be "::", it would just be ":"
to start the value, because your field above parses as ":1470205476" for
the value and will be rewritten like this along the path by many
implementations :

    Date: :1470205476

Willy

Reply | Threaded
Open this post in threaded view
|

Re: If not JSON, what then ?

Poul-Henning Kamp
In reply to this post by Martin Thomson-3
--------
In message <CABkgnnWAeFm2rFY=[hidden email]>, Martin Thomson writes:
>On 2 August 2016 at 22:01, Poul-Henning Kamp <[hidden email]> wrote:
>> Thinking about it now, I can't recall any headers starting with a '('
>> so () might be better than <> and thus avoid the special case of Link.
>
>
>Or ><?

Ohh ... neat thinking...

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

123