Aws-lambda-dotnet: Getting binary support working in blueprint ASP.NET Core Web App

Created on 8 Mar 2018 · 5Comments · Source: aws/aws-lambda-dotnet

I am having some problems getting binary support working with the ASP.NET Core 2 integration.

So I tried with the "ASP.NET Core Web App" blueprint, and it actually contains a favicon.ico file, which is not displayed when published.

I think the blueprint should work out of the box in the same way as running on your own machine. Or maybe you should just remove the favicon.ico.

I read the instructions with regards to Binary Response Content here: https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.AspNetCoreServer/README.md

So I added the following line to LambdaEntryPoint.Init(): RegisterResponseContentEncodingForContentType("image/x-icon", ResponseContentEncoding.Base64);

And I added the Binary Media Type in console:

Lambda log correctly shows that response is base64 encoded:

START RequestId: 11a7e691-22d3-11e8-9b13-ef274abd9c03 Version: $LATEST
Incoming GET requests to /favicon.ico
ASP.NET Core Request PathBase: /Prod, Path: /favicon.ico
[Information] Microsoft.AspNetCore.Hosting.Internal.WebHost: Request starting GET https://XXX.execute-api.eu-west-1.amazonaws.com/Prod/favicon.ico 
[Information] Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware: Sending file. Request path: '/favicon.ico'. Physical path: '/var/task/wwwroot/favicon.ico' 
[Information] Microsoft.AspNetCore.Hosting.Internal.WebHost: Request finished in 0.5675ms 200 image/x-icon 
Response Base 64 Encoded: True
END RequestId: 11a7e691-22d3-11e8-9b13-ef274abd9c03

API Gateway log:

Starting execution for request: 577e5bb3-22d4-11e8-b061-1775958b34a4
HTTP Method: GET, Resource Path: /favicon.ico
Successfully completed execution
Method completed with status: 200

What part am I missing?

I found quite many posts with people not making binary work with the lambda proxy integration. So I suspect there is a general issue.

guidance

Source

mbp

Most helpful comment

I'm just going to leave this here so it hopefully saves someone else an hour...

The default "Accept" header in the request for .png files is "image/apng" not "image/png"! Everything worked once I added:

        protected override void Init(IWebHostBuilder builder)
        {
            //NB: Serverless WebAPI needs to have special config to serve binary file types: 
            RegisterResponseContentEncodingForContentType("image/png", ResponseContentEncoding.Base64);
            RegisterResponseContentEncodingForContentType("image/jpeg", ResponseContentEncoding.Base64);
            RegisterResponseContentEncodingForContentType("image/gif", ResponseContentEncoding.Base64);
            RegisterResponseContentEncodingForContentType("image/apng", ResponseContentEncoding.Base64);
            RegisterResponseContentEncodingForContentType("image/webp", ResponseContentEncoding.Base64);
            RegisterResponseContentEncodingForContentType("image/x-icon", ResponseContentEncoding.Base64);

            builder
                .UseStartup<Startup>();
        }

Edit: Accept headers for Chrome and IE11 seem to use image/apng as default but Firefox sends */* for <img> tags! You can add */* to the above list, and it _seems_ to work but YMMV.

badcommandorfilename on 20 Apr 2018

👍4 🚀1

All 5 comments

I resolved this issue when talking to AWS Support.

The solution:
After changing "Binary Media Types", you must go and click "Deploy API":

mbp on 15 Mar 2018

Hey bro, I followed your steps but still could not get the image/icon.

Did you do anything more than what you said?

Thanks!

cjnoname on 20 Mar 2018

Yeah, actually you need to set BinaryMediaTypes to */* when trying to show the image in the browser.

BinaryMediaType image/x-icon will only work if client sends Accept header. Here is a way to test:

$ curl -sH "Accept: image/x-icon" https://XXX.execute-api.eu-west-1.amazonaws.com/Prod/favicon.ico -o /tmp/favicon.ico
$ file /tmp/favicon.ico
/tmp/favicon.ico: MS Windows icon resource - 3 icons, 16x16, 256-colors

mbp on 20 Mar 2018

ignore it :)