HTTP2 Server Push doesn't include Authorization header into the push request made from Link: preload header

[Dalibor Karlović]

I have Nginx setup as a reverse proxy in front of my Varnish-enabled API app. API is using OAuth2 auth, requiring a Authorization header.

Relevant config:

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    server_name _;

    location / {
        proxy_pass http://proxy/;
        http2_push_preload on;
    }
}

If I try to access an endpoint of my app, it will include the expected HTTP2 Server Push header:

 nghttp https://app.local/api/images/ee4241d8-aa01-11e9-b3e4-0242ac1f000b   -H 'Accept: application/json'   -H 'Accept-Language: hr'   -H 'Authorization: Bearer Zjc1MzQzM2ZlN2IzZWIxOTY1ZDE2YjlkZjI3NjU0MmMxYWVhNmRhMWI1ZjExODRiMDVkNGU4YmM0MGU5NmRjMg' -v

...
[  0.034] recv (stream_id=13) link: </api/images/f112c18a-aa01-11e9-bb11-0242ac1f000c/metadata>; rel="preload"
...

Nginx will subsequently create the second request, but this one will return "OAuth2 authentication required", because the Authorization header is mission on the subsequent (Nginx-triggered) request:

[  0.311] recv (stream_id=2) www-authenticate: Bearer realm="Service", error="access_denied", error_description="OAuth2 authentication required"
{"error":"access_denied","error_description":"OAuth2 authentication required"}
[  0.311] recv DATA frame <length=78, flags=0x01, stream_id=2>
          ; END_STREAM

Looking at Varnish debug log, the headers Nginx sends seem to be:

-   ReqMethod      GET
-   ReqURL         /api/images/f112c18a-aa01-11e9-bb11-0242ac1f000c/metadata
-   ReqProtocol    HTTP/1.0
-   ReqHeader      Host: proxy
-   ReqHeader      Connection: close
-   ReqHeader      accept-encoding: gzip, deflate
-   ReqHeader      accept-language: hr
-   ReqHeader      user-agent: nghttp2/1.38.0
-   ReqHeader      X-Forwarded-For: 172.31.0.13

Since the Authorization header is not present, Varnish obviously cannot pass it further and the application is correct to fail.

The header looks like it should be included. I'm pretty sure Accept header is also missing, but cannot be sure since it might get eaten by Varnish.

[Dalibor Karlović]

Accept header is also definitely missing.

[Ruslan Ermilov]

Regarding the "Accept" header, please see this discussion: ​http://mailman.nginx.org/pipermail/nginx-devel/2018-February/010809.html

Regarding the "Authorization" header, the pushed resource can easily have a different realm, so we can't assume that the same credentials apply.

This problem has been discussed in the HTTP WG before HTTP/2 was ratified as the standard:
​https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0039.html
​https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0041.html
​https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0087.html

Generally, it's a bad idea to push resources that imply negotiation with the client.

[Dalibor Karlović]

Hi,

I understand the motivation behind obscuring these headers since they pose a compatibility / security risk.

However, this does mean Nginx is not capable of proxying modern REST-based APIs based on server push:

• ​https://blog.runscope.com/posts/you-might-not-need-graphql
• ​https://dunglas.fr/2019/01/api-platform-2-4/
• ​https://api-platform.com/docs/core/push-relations/

With HTTP/2 gaining more widespread support and these kinds of integrations already available to developers, leveraging Server Push for APIs seems like a great fit, while taking advantage of existing HTTP infrastructure and is likely to come in widespread use in the future.

What do you think about a feature which would allow the configuration to whitelist specific headers from incoming request into the preload request?

Example:

server {
    location / {
        proxy_pass http://proxy/;
        http2_push_preload on;
    }

    location / {
        # list of headers to copy from incoming request to preload request
        http2_push_preload_headers Authentication Accept Accept-Language;
    }

    # alternatively
    location /api {
        # list of headers to add to preload request

        # copy from incoming request
        http2_push_preload_header Authentication $http_authentication;
        http2_push_preload_header Accept $http_accept;
        http2_push_preload_header Accept-Language $http_accept_language;

        # fully custom request
        http2_push_preload_header X-Custom-Header yes;
    }
}

This would give developers the tools to still handle this use case, while having the burden of everything being secure (not leaking access tokens and cookies to 3rd party realms) and compatible (origin servers expect headers as-is).

[Maxim Dounin]

See also #1851.