W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP 1.1 --> 2.0 Upgrade

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Mon, 20 Aug 2012 05:35:24 -0400
Message-ID: <CAMm+LwgGqDV0hEAjQGAi8kwCxRyFy4bH-wYbAKgFXdacxGSg-A@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Julian Reschke <julian.reschke@gmx.de>, Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I think we need a lot more explanation of what this intermediary chain
is and which side of the wall it lies.

Configuration of server side proxies such as squid has zero impact on
this issue. Server installations that support HTTP/2.0 will be
appropriately configured.

Are client side proxies really more than a corner case issue today?
When we first developed them the whole of CERN was sitting on a T1 and
caching was a critical concern. Only a small percentage of the HTML on
the Web is even cachable.

Content Delivery Networks have caching but they work in a very
different way to HTTP caching.


I am pretty skeptical as to the value of firewall proxies when most
let port 443 through.



On Mon, Aug 20, 2012 at 4:49 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Mon, Aug 20, 2012 at 10:25:46AM +0200, Julian Reschke wrote:
>> On 2012-08-20 10:16, Yoav Nir wrote:
>> >Hi
>> >
>> >There's been a recent discussion about signaling support for HTTP 2.0 in
>> >the DNS. I think that is a good way to go about it, but it doesn't cover
>> >all cases.
>> >
>> >I believe there is value in an upgrade mechanism, for example for home
>> >routers and other devices that use HTTP for configuration long before
>> >(if ever) they have DNS entries, let alone SRV records.  While such a
>> >mechanism may also be useful for HTTPS, something like NPN can be used
>> >as part of the TLS handshake.
>> >
>> >So here's my proposal:
>> >
>> > 1. When first connecting to a website, the client begins with HTTP
>> > 1.0/1.1.
>> > 2. A server that supports HTTP/2.0 responds with a new header:
>> >    "HTTP-VERSIONS: 1.1,2.0". This header is included in the server's
>> >    response to the client's request.
>>
>> There's already an "Upgrade" header field for that.
>
> +1.
>
> All this work has been done over and over for WebSocket, I don't see
> why we need to reinvent the wheel.
>
> Upgrade was designed *exactly* for that purpose and fits it very well.
> Moreover it is the only one (along with NPN) which considers the
> intermediary chain, while side-band mechanisms (such as DNS) cannot
> take that into account.
>
> Best regards,
> Willy
>
>



-- 
Website: http://hallambaker.com/
Received on Monday, 20 August 2012 09:35:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 August 2012 09:35:58 GMT