Re: structured headers "why not JSON" FAQ

Hi Julian,

On Wed, Jun 13, 2018 at 01:04:11PM +0200, Julian Reschke wrote:
> > > If the spec makes a mandatory requirement on the recipient that is easy to implement, why would implementations choose to follow it for SH but not for JFV?
> > 
> > Because the option of deploying a JSON implementation *without* those constraints is extremely easy.
> I don't buy that argument.

Speaking as an implementer of intermediary, it's a huge pain to have to deal
with non-compliance in field. The intermediary always appears after clients
and servers were already working together, and reveals non-compliance by
breaking what used to work. And the users in place don't want to listen to
your arguments nor read the RFC you put under their noze, they simply say
"but it was working fine, it's stupid to be extremist like this". And it's
very likely getting worse with microservices because lots of server-side
components are themselves clients as well, so the client and the server
code are developed by the same person who refuses to read specs and thinks
he/she knows. To give you an example, I've already seen people send base64
in headers with the LF at the end of each line. It used to work only because
of line folding and tolerance for single LF. With haproxy in the middle
replacing the LF with an LWS, it broke. The guy told me "but there's no
problem doing this, the proof is that it works". The reality is that this
person had no clue how to encode his PEM certificate and figured that simply
sending it into a header field was enough to retrieve it unmollested on the
other side.

As we already discussed, while I don't like JSON much I have no strong feeling
against it either and your JFV proposal certainly remains a good one overall.
But we really cannot dismiss this risk of reusing libraries whose scope was
clearly not to be placed into headers nor to respect the imposed constraints
because 99.9% of the time it will work, and some of us will have to deal with
the 0.1% remaining once it's too late to fix the end points :-/


Received on Wednesday, 13 June 2018 21:45:32 UTC