[squid-dev] HTTP meetup in Stockholm

[Amos Jeffries]

On 12/07/2016 9:00 a.m., Kinkie wrote:
> On Mon, Jul 11, 2016 at 9:05 PM, Alex Rousskov <
> rousskov at measurement-factory.com> wrote:
> 
>> On 07/10/2016 04:33 AM, Kinkie wrote:
>>> at the end of the month I will attend the HTTP meetup in Stockholm.
>>> Besides having a chance to see Henrik, I'd like to collect your feedback
>>> and opinions on the topic that are likely to be touched.
>>>
>>> Currently there is rather hot discussion on the mailing list on the
>>> topics of JSON headers
>>> (https://tools.ietf.org/html/draft-ietf-httpbis-jfv-01), secondary
>>> certificate authentication
>>> (
>> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01
>> ),
>>> cache digests
>>> (https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-00). Other
>>> topics of discussion have tapered off.
>>> What is the project's position I should bring to the table, if requested?
>>
>> You are asking for a Project position on complex, new, and actively
>> changing issues when we cannot agree on simple things like removing
>> unused broken code and hardly have enough time to fix major bugs...
>>
> 
> IVHMO it's easier to have an opinion than to fix bugs ;)
> Anyway:
> 
> Regarding JSON encoding of HTTP headers: IMO it's a good thing and we
> should support it. JSON is emerging as a lingua franca for
> machine-to-machine communication and this is a reasonable extension.

I'm much more in favour of binary formats. The HTTP/2 HPACK design lends
itself very easily to binary header values (ie sending integers as
interger encoded value). Following PHK's lead on those.

But the JSON stuff does seem to have a lot of traction and we can-do
whatever, even though its not ideal to have a text format for the shiny
new future stuff.


I was in favour when it was being talked about as just a framework for
RFC authors to use to get their ABNF designs right.

But now that talk has turned to actually using JSON on-wire there is a
big potential trainwreck ahead with the security issues from duplicated
headers.

Willy T.'s recent posts have been pointing that problem out these past
two days. So it may be resolved by the workshop. But the counter
arguments are currently all about how valid JSON implementations wont
generate such crap. It's not the valid senders security people worry
about, its the crafted nasties that receivers are subjected to.


> 
> HTTP2 Additional Certs: this will probably mean a significant amount of
> work to support. I suspect our hand will be forced by browser implementors,
> I see no reason to support this at this time.

Nod. It has got some uses but I'm deferring having any strong opinion on
the details. Our TLS implementation has a long way to go before we can
join in.

> 
> Cache Digests: this is http2 only (there was a burst of discussion on
> whether to use headers for the purpose instead of http2 frames), so it's a
> way off. We are not really going to be impacted on this path, but we could
> benefit if we can manage to cache server-pushed content. I'd therefore
> support this proposal.

Agreed. I've written to the WG already on all our behalf for the draft
adoption vote: In favour, but not ready to join the early adopters or
testers. Solely due to the state of our HTTP/2.


>>
>> If you have carefully researched those HTTP Working Group issues, then I
>> am sure your personal position would be almost as valuable as the
>> official Project position (and please post your summary here!). If you
>> have not researched them, then just say "we will do whatever Google
>> forces us to do" whenever asked :-).
>>
> 
> Carefully is a bit strong a word; I have tried to understand the context
> and have some insight into the topics.
> 
> 
>> Envious Alex.
>>
> 
> I see a massive case of imposter syndrome in my close future ;)
> If you wish, let's establish checkpoints during the workshop; I'll try to
> be on IRC to have a channel with you guys.
> 

:-)

I might take you up on that. What UTC timestamps is that turning out to be?


Amos