Aws-lambda-dotnet: Erhalten von Binärunterstützung in Blueprint ASP.NET Core Web App

Erstellt am 8. März 2018 · 5Kommentare · Quelle: aws/aws-lambda-dotnet

Ich habe einige Probleme mit der Binärunterstützung, die mit der ASP.NET Core 2-Integration funktioniert.

Also habe ich es mit dem Blueprint "ASP.NET Core Web App" versucht, und er enthält tatsächlich eine favicon.ico Datei, die bei der Veröffentlichung nicht angezeigt wird.

Ich denke, die Blaupause sollte sofort einsatzbereit sein, so wie sie auf Ihrem eigenen Computer ausgeführt wird. Oder vielleicht sollten Sie einfach das favicon.ico entfernen.

Ich habe die Anweisungen in Bezug auf den Inhalt von Binärantworten hier gelesen: https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.AspNetCoreServer/README.md

Also habe ich die folgende Zeile zu LambdaEntryPoint.Init() hinzugefügt: RegisterResponseContentEncodingForContentType("image/x-icon", ResponseContentEncoding.Base64);

Und ich habe den binären Medientyp in der Konsole hinzugefügt:

Das Lambda-Protokoll zeigt korrekt, dass die Antwort base64-codiert ist:

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-Protokoll:

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

Welcher Teil fehlt mir?

Ich habe ziemlich viele Posts mit Leuten gefunden, die mit der Lambda-Proxy-Integration keine Binärarbeit machen. Daher vermute ich, dass es sich um ein allgemeines Problem handelt.

guidance

Quelle

mbp

Hilfreichster Kommentar

Ich lasse das einfach hier, damit es hoffentlich jemand anderem eine Stunde spart...

Der Standard-Header "Accept" in der Anforderung von .png-Dateien ist "image/ a png" und nicht "image/png"! Alles funktionierte, als ich hinzufügte:

        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>();
        }

Bearbeiten: Accept-Header für Chrome und IE11 scheinen standardmäßig image/apng zu verwenden, aber Firefox sendet */* für <img> Tags! Sie können der obigen Liste */* hinzufügen, und es _scheint_ zu funktionieren, aber YMMV.

badcommandorfilename am 20. Apr. 2018

👍4 🚀1

Alle 5 Kommentare

Ich habe dieses Problem im Gespräch mit dem AWS-Support gelöst.

Die Lösung:
Nachdem Sie "Binary Media Types" geändert haben, müssen Sie auf "Deploy API" klicken:

mbp am 15. März 2018

Hey Bro, ich habe deine Schritte befolgt, konnte aber das Bild/Symbol immer noch nicht abrufen.

Hast du mehr getan, als du gesagt hast?

Vielen Dank!

cjnoname am 20. März 2018

Ja, eigentlich müssen Sie BinaryMediaTypes auf */* wenn Sie versuchen, das Bild im Browser anzuzeigen.

BinaryMediaType image/x-icon funktioniert nur, wenn der Client den Accept Header sendet. Hier ist eine Möglichkeit zum Testen:

$ 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 am 20. März 2018

ignoriere es :)