[feature req] Server Push with httpd and mod_pagespeed over HTTP/2

165 views
Skip to first unread message

Guillaume Rossolini

unread,
Jan 19, 2016, 7:49:14 AM1/19/16
to mod-pagespeed-discuss
Hi,

I know this might not the best group to post this, but please bear with me.

I have been following the recent developments of httpd, and especially mod_h2 and its H2Push directive that appeared in v2.4.18. I see this feature as a possible improvement over resource inlining, especially for above-the-fold resources. 

From a testing point of view, the "nghttp" tool won't accept pushed resources when they are hosted on a different domain than the Document.
From a webserver point of view, it seems this directive is able to send PUSH PROMISEs when there is a link HTTP header in the response, but only in certain conditions. For example, httpd doesn't send a PUSH PROMISE when the link contains a fully qualified URL to another domain.

link: </favicon.ico>;rel=preload
=> recv PUSH_PROMISE frame <length=..., flags=..., stream_id=...>

=> recv PUSH_PROMISE frame <length=..., flags=..., stream_id=...>

However, I am looking for a way to make use of this in a sharded domain setting like this (other domain + filename mappings):


Since mod_pagespeed already has logic for domain mapping and background resource fetching, I was hoping it could be a feature sometine in the future?
Or, if it is not desired in pagespeed itself, maybe the mod_pagespeed team could help brainstorm use cases and pitfalls with the mod_h2 developers so their module can support resources from other domains?

Thanks,

Jeff Kaufman

unread,
Jan 19, 2016, 9:09:43 AM1/19/16
to mod-pagespeed-discuss
If I'm reading you correctly, you want to send cross-domain http/2
server pushes? So a.com would push b.com/script.js? Unfortunately
the problem here goes beyond fetching: cross domain server push isn't
supported by http/2.

(If a.com could push b.com/script.js, how would the browser verify
that b.com was ok with this?)
> --
> You received this message because you are subscribed to the Google Groups
> "mod-pagespeed-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mod-pagespeed-di...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mod-pagespeed-discuss/0ef30a05-d752-47ff-8146-2d59eed47c51%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Guillaume Rossolini

unread,
Jan 19, 2016, 9:43:08 AM1/19/16
to mod-pagespeed-discuss
Yes that's it exactly.

It seems to me mod_pagespeed follows the same reasoning to whitelist domains and resource types: mod_pagespeed can be configured to include inlined script from b.com/script.js into a.com/index.html
There is a security issue, a bandwidth issue, a caching issue etc., all of which were resolved in mod_pagespeed thanks to configuration options.

I can see use cases where similar configuration would benefit legitimate use cases for cross domain Server Push, ie. when assets are split over several domains but are still owned by the same application.

In your example, I am not sure I understand why b.com would not be ok with this, as what you describe is already being done at the HTML level in many situations. The only difference would be that b.com's client would be a.com instead of the browser.

However, if the HTTP/2 spec does not suport this as you say, I'm not sure I'll pursue this any further.

Regards,

Joshua Marantz

unread,
Jan 19, 2016, 9:54:32 AM1/19/16
to mod-pagespeed-discuss
In general we are indeed looking at ways to improve site performance under h2, and server-push is one of them.  Our current thinking, though, is that from MPS we can specify likely-to-be-needed resources as Preload hints in the http response headers.  It is then up to the h2 support in the server (be in mod_h2 or nginx native support) to interpret that as server-push.

We can certainly add preload hints for off-domain resources.  But then it's a question of how the server h2 integration and the browsers will interpret those hints.

However, as with all things h2, we should probably spend some effort actually testing what works best in practice.  For example, if a resource is really tiny (e.g. a <500 byte png used for a a stylized border), then base64 encoding might be better than server-push.  At some threshold, server-push makes sense, such as (say) a 10k javascript file which would otherwise block the browser from prescanning.

Here is a similar enlightening study from Kahn Academy on their experience with combining JS files vs relying on h2 multiplexing: http://engineering.khanacademy.org/posts/js-packaging-http2.htm

-Josh

-Josh

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/9c636b88-8c50-4876-afd8-b7ee55de578d%40googlegroups.com.

Jeff Kaufman

unread,
Jan 19, 2016, 9:55:58 AM1/19/16
to mod-pagespeed-discuss
Part of the problem is that once the resource is pushed it would be
available in cache for anyone who wanted to access b.com/script.js, so
letting anyone push anything would allow cache poisoning attacks.
This doesn't apply with inlining, because the pushed resource is
scoped to the containing document.

On Tue, Jan 19, 2016 at 9:43 AM, Guillaume Rossolini
>> > email to mod-pagespeed-di...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/mod-pagespeed-discuss/0ef30a05-d752-47ff-8146-2d59eed47c51%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mod-pagespeed-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mod-pagespeed-di...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mod-pagespeed-discuss/9c636b88-8c50-4876-afd8-b7ee55de578d%40googlegroups.com.

Guillaume Rossolini

unread,
Jan 19, 2016, 6:49:05 PM1/19/16
to mod-pagespeed-discuss
Hi,

I would venture that not anyone should be able to push resources from hosts they do not control. This could be controlled by several existing technologies, one of them being crossdomain (XML) files, but must assume you know of this and I am missing something.

Some part of the responsibility falls to the browser/client, and some other part of the responsibility falls to the server.
Whatever the client asks for, the server does not need to oblige. Of course, the reverse is also true: whatever the server sends, the client should feel free to ignore.

"once the resource is pushed", it would be available to any resource that should have access to it. Is this a problem? With a proper whitelisting or filtering mecanism, is it still a danger?

Regards,
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/mod-pagespeed-discuss/0ef30a05-d752-47ff-8146-2d59eed47c51%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "mod-pagespeed-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an

Jeff Kaufman

unread,
Jan 20, 2016, 8:46:25 AM1/20/16
to mod-pagespeed-discuss
On Tue, Jan 19, 2016 at 6:49 PM, Guillaume Rossolini
<guillaume...@instantluxe.com> wrote:
> I would venture that not anyone should be able to push resources from hosts
> they do not control. This could be controlled by several existing
> technologies, one of them being crossdomain (XML) files, but must assume you
> know of this and I am missing something.
>

For cross domain server push to be useful you'd have to be able to do:

a.com/index.html
-> pushed b.com/script.js

without making a connection to b.com to verify that this push was
authorized. (If you're going to connected to b.com regardless you
might as well just load the script from there.)

> Some part of the responsibility falls to the browser/client, and some other
> part of the responsibility falls to the server.
> Whatever the client asks for, the server does not need to oblige. Of course,
> the reverse is also true: whatever the server sends, the client should feel
> free to ignore.

Well, ok, nothing stops you from doing cross domain server push on the
server end, but any client will drop the pushed resource because
that's what the spec says. If you want to be able to do this here you
need to figure out how to extend the spec to allow this pushing
without making this insecure.

> "once the resource is pushed", it would be available to any resource that
> should have access to it. Is this a problem? With a proper whitelisting or
> filtering mecanism, is it still a danger?
>

What do you mean by a "proper whitelisting and filtering mechanism"?

Guillaume Rossolini

unread,
Jan 20, 2016, 9:03:17 AM1/20/16
to mod-pagespeed-discuss
Hi Jeff

Thank you for this information.
If the client is going to ignore the pushed resource anyway, that answers my question completely: I won't pursue this project any longer.

Regards,
Reply all
Reply to author
Forward
0 new messages