Re: Response to HTTP2 expresions of interest

I disagree with the claim that the current http charter is not designed for
the next 20 years. It is, and spdy is.

I have yet to see any proposals of something better or missing from the
current proposals. If there are better ideas, by all means raise them.
Please be detailed and offer proof where possible.

Mike
On Jul 14, 2012 2:02 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

> If this is worth doing at all it is something that can be most easily
> performed in a HTTP/2.0 context where the whole legacy question
> becomes moot-ish
>
>
>
> On Sat, Jul 14, 2012 at 2:32 PM, HAYASHI, Tatsuya
> <lef.mutualauth@gmail.com> wrote:
> > PHK's ideal world, I also share it.
> >
> > However, it is not understood whether it is contained in the present
> > WG charter.
> > I still think that our goal is ambiguous.
> >
> > To speak of extremes, we have a two targets.
> >
> > 1)
> > Efficiency is improved. and compatibility is maintained as much as
> possible.
> > 2)
> > The ideal which deserves HTTP/2.0 and which can be used for 20 years
> > or more is aimed at.
> >
> > These are not contrary.
> > We have to pursue the both as much as possible.
> > But, The semantics must not change.
> >
> > I think that the name of HTTP/2.0 is making a goal difficultly.
> >
> > I thinking...
> > ex) HTTP layer Session is necessity?
> >   If it is HTTP/1.1tris?
> >   If it is HTTP/1.2?
> >   and If it is HTTP/2.0?
> >
> > We need to deepen an concrete discussion more.
> >
> > --
> > HAYASHI, Tatsuya
> > Lepidum Co. Ltd.
> >
> > On Sat, Jul 14, 2012 at 2:52 PM, Willy Tarreau <w@1wt.eu> wrote:
> >> On Fri, Jul 13, 2012 at 08:21:03PM -0700, Tim Bray wrote:
> >>> On Fri, Jul 13, 2012 at 11:21 AM, Poul-Henning Kamp <
> phk@phk.freebsd.dk>wrote:
> >>>
> >>>
> >>> > TLS communication today already have an envelope consisting of
> >>> > IP# + TCP port numbers, and unless your adversary is totally
> >>> > incompetent, he also has the DNS lookup that gave you that IP#.
> >>> >
> >>> > QED: Putting the "Host:" in the HTTP envelope does not leak any
> >>> > information your adversary doesn't already have or can guess.
> >>> >
> >>>
> >>> That?s just not true.  There are lots of ways to get to a particular
> origin
> >>> server, and I would think that for a malicious person in the middle,
> the
> >>> Host header would be more interesting than the ostensible IP address.
>  On
> >>> the other hand, I do understand why a payload-oblivious load balancer
> would
> >>> need to see that header.  It is simply the case that we have two
> objectives
> >>> which are apparently in conflict. No, I don?t have a solution (or even
> a
> >>> strong opinion, yet, although I?m inclined to err on the side of
> protecting
> >>> user privacy at the expense of almost all else).  -Tim
> >>
> >> Well, TLS offers SNI which also reveals the Host header in clear text,
> so
> >> your extreme view of privacy doesn't seem to be shared as much wich even
> >> these guys. Also, building a protocol fortress that prevents anyone from
> >> implementing it in real life is an effective way of protecting user
> privacy
> >> since the user won't have access to anything and thus won't reveal his
> >> intents. Maybe some people would even consider that revealing they have
> >> access to the internet affects their privacy so they need an invisible
> >> connection... At one point a limit must be set, otherwise it becomes
> >> totally non-sense. Host and IP are reasonably interchangeable, are used
> >> for routing the protocol to its destination, and if someone doesn't want
> >> to show what host he's going to, he'd better leave the net. And if even
> >> the TLS guys accept this, then I think this is a much acceptable limit.
> >>
> >> Regards,
> >> Willy
> >>
> >>
>
>
>
> --
> Website: http://hallambaker.com/
>
>