Re: http/2 server-push support

2019-02-28 Thread Willy Tarreau
Hi Patrick,

On Tue, Feb 26, 2019 at 02:13:28PM -0500, Patrick Hemmer wrote:
> Now that we have h2 support on frontends, backends, trailers, etc, I'm
> hoping that server side server-push is somewhere on the roadmap. By
> "server side" I mean not this middleware based server-push methodology
> frequently used where a "Link" header is converted to a server push. But
> instead where the server itself can generate the server-push responses.
> 
> Is there any plan on this, or when it might be available?

No and it really is even less than what we could initially imagine.
There's still no real consensus on server push benefits, as it causes
as many problems as it solves and it's a matter of balance depending on
the use cases. For some people it significantly increases bandwidth
usage and page load time by delivering objects that are already present
on the client. For others it's beneficial. In terms of protocol design
it's a disaster in my personal opinion. The Early Hints (103) is way
cleaner in that it lets the client decide what to fetch. Until recently
it was not even sure that push would still exist in HTTP/3 as it really
doesn't get any more love than it deserves from protocol designers.

It was designed as an alternative to server-side inlining, by which
some products were assembling javascript and CSS into the main HTML
page to reduce the number of round trips, and as a result caused
exactly the same benefits and trouble.

> If it helps for prioritization, our use case for this is reduce
> processing overhead. A single request might require the client to have
> related resources, and those related resources might all involve
> computation that is shared. If each request is handled separately (e.g.
> Link header to server-push conversion), it would result in a lot of
> duplicated work. So instead we want to do the computation once, and push
> out the multiple responses separately.

It's unclear to me what side's processing you're trying to reduce this
way, as each participant in the chain has the same number of requests
and responses to process, except that push is even slightly more
expensive for the client since it has to parse a request while normally
a client doesn't parse requests but only emits them.

Thanks,
Willy



Re: http/2 server-push support

2019-02-27 Thread Aleksandar Lazic
Hi Patrick.

Am 26.02.2019 um 20:13 schrieb Patrick Hemmer:
> Now that we have h2 support on frontends, backends, trailers, etc, I'm hoping
> that server side server-push is somewhere on the roadmap. By "server side" I
> mean not this middleware based server-push methodology frequently used where a
> "Link" header is converted to a server push. But instead where the server 
> itself
> can generate the server-push responses.

What do you mean that the HAProxy should do as a proxy and what's wrong with
"Link" header?

As far as I understand the server-push is a method that a server side updates
the client like in chat application.

It would be nice to understand your idea and your use case to see what and how
HAProxy can handle it.

> Is there any plan on this, or when it might be available?
> 
> If it helps for prioritization, our use case for this is reduce processing
> overhead. A single request might require the client to have related resources,
> and those related resources might all involve computation that is shared. If
> each request is handled separately (e.g. Link header to server-push 
> conversion),
> it would result in a lot of duplicated work. So instead we want to do the
> computation once, and push out the multiple responses separately.
> 
> -Patrick

Regards
Aleks