Re: draft-ietf-httpbis-http2-01, "4.2.3 Authentication"

["Nicolas Mailhot" <[e-mail]>]

Le Mer 6 mars 2013 15:31, Julian Reschke a écrit :
> On 2013-03-06 14:52, Nicolas Mailhot wrote:
>> Hi,
>>
>> Unless I've missed something, the draft as it stands does not answer the
>> following questions:
>> ...
>> Surely, HTTP2-FL can do better than this
>
> It seems to me that all you said applies to HTTP/1.1 as well.

Sure, however HTTP/1.1 does not include all the streaming/framing
infrastructure that begs to be used to resolve this issue. It seems to me
that it only arose because HTTP/1 was "too simple" to cope with such uses.

> My
> understanding was that how authentication works should be orthogonal to
> the HTTP message format, and thus whatever needs to be fixed should be
> fixed for both message formats.

Actually, basic auth over ssl is good enough now for most uses. No need to
invent new auth schemes. What's not good enough is transporting the
credential to the intermediary. And that is more an HTTP transport problem
than an http-auth WG problem IMHO. Also, you need to keep some
relationship between the intermediated streams and the associated auth, so
it can't be solved without some protocol support (or, you end up
authorising client IPs, which sucks from a security point of view, and is
not reliable when clients connection to the network switches from wifi to
wire to whatever else is going to exist in the future)

> As such, I would expect this to be
> material for the new http-auth WG.

Honestly, I think that at this point of time, fixing in HTTP/1 would be
nice but should not block fixing in HTTP/2. I doubt any fix in HTTP/1
would be picked up by HTTP/1 intermediary manufacturers without major
reving-up, which will make 'fixed HTTP/1 intermediary' as expensive as
'working-by-default HTTP/2'. So most intermediary users will go the HTTP/2
intermediary route anyway (as long as major browsers support HTTP/2 and
HTTP/2 allows HTTP/2-intermediary to HTTP/1 site use).

So the priority should be *not* to propagate this HTTP/1 problem to
HTTP/2, and have it just work in HTTP/2 by default.

(I know intermediary issues have been a pain to SPDY proponents, but
intermediaries would be enthusiastic adopters of HTTP/2 if it solved their
HTTP/1 problems. And since intermediaries are centralised by nature,
they're much easier to redeploy than changing countless web sites to use
HTTP/2)

Best regards,

-- 
Nicolas Mailhot