Re: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

[Willy Tarreau <[e-mail]>]

Hi Nicolas,

On Fri, Apr 27, 2012 at 09:16:00AM +0000, Nicolas Mailhot wrote:
> Hi,
> 
> Would it be possible to publish a list of specific questions and have each
> proposal submitter answer how its proposal answers each of them? Just to make
> sure no use-case falls through the cracks? Sure one can read each proposal and
> guess the answers, but I think proposal submitters are the best to answer how
> their proposal could be used. And this way one won't have to fish list archives
> for answers to common questions.

I'm not sure this will help make great progress in the short term (only 1.5
month is left for proposals, and working on them takes a *lot* of time).

> I'd especially like an answer to the following:
> 
> 1. Can the proposal permit secure http/2.0 communication without letting malware
> punch random protocols through firewalls using the http/2.0 secure port?

You'll never ever be able to guarantee this. Malware can use whatever
encapsulation they need. Some communicate via text messages on twitter.
The rule is simple : if at least one bit can leave a place, it is possible
to communicate with the outside world. So this is totally out of the scope
of future designs.

> 2. How can intermediary network nodes request (re-)authentication on secure
> networks when client credentials expire?

Unless I miss your point, that's what the 401 is about, no ?

> 3. How can they communicate authentication location to the client (or is it
> implied and how)? Does this mechanism work for dumb (not-browser) web clients?
> 
> 4. How could other intermediary messaging be handled?

I'm not sure I get these points.

> 5. Is the proposed protocol feature-complete or does it require an http/1.1
> downgrade to handle some existing http use-cases (esp. proxy ones)?

It needs to be able to completely replace it otherwise it will mean much
more work for many implementers, leading to many more bugs and interop
issues.

> 6. Is the http/2.0 namespace a superset of the http/1.1 namespace? Are error
> codes specific to the protocol version used or should it be assumed they'd apply
> the same if the protocol was up/down graded?

Since we have to be able to be able to transport 1.1 over 2.0 with "reasonable
fidelity", I think we should at least be able to adopt the existing namespace
whatever it's encoded.

> 7. How will the proposal make writing tools that process HTTP headers and logs
> simpler? Does it reduce HTTP reliance on conventions not commonly used in
> mainstream application writing?

This depends on proposals but it seems like everyone agrees that right now
the syntax is too lax and that we must make it a bit more strict.

> 8. Does it add specific logging constrains that didn't exist in http/1.1?

Logging is out of the scope of HTTP in my opinion as it's an implementation
choice.

> 9. How will the proposal improve network efficiency?

At least by reducing message sizes, packet counts and connection counts.

Regards,
Willy