can't bypass non-image file

[syu2222]

We have deployed serverless-image-handler and it works well with the images. But our cloudfront linked S3 also store pdf and txt files. When we try to access those pdf and txt files through the cloudfront url, we get internal errors.
How to make the serverless handler simply return the requested pdf and txt files through the cloudfront and S3?

[ralcar]

Did you find a solution to this? I am in this same position

[syu2222]

I create a separate cdn for the non image files. Sent from Yahoo Mail for iPhone On Wednesday, September 19, 2018, 5:34 AM, Ralf Carneborn <notifications@github.com> wrote: Did you find a solution to this? I am in this same position — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mattcrowe]

For anyone else with this issue, you can add new Behavior/s in your Cloudfront distribution for other file types that use your s3 bucket/s as the Origin.

[hayesry]

Hi @syu2222. Thanks for bringing this to our attention. We're currently working on a series of updates (i.e. better handling of non-images, support for multiple S3 buckets) that should mitigate this issue in the next version of the solution. Stay tuned!

[brosbunbo]

Do we have any update for this? Thanks.

[shsenior]

Resolved with v4.0.0

[Lunteer]

@shsenior I just setup the latest version and got the following error when trying to access a CSS file in the same bucket ...

`

status	400
code	"RequestTypeError"
message	"The type of request you are making could not be processed. Please ensure that your original image is of a supported file type (jpg, png, tiff, webp) and that your image request is provided in the correct syntax. Refer to the documentation for additional guidance on forming image requests."
`
Is there a setting I need to setup or was this supposed to be something automatically?

I have used other Lambda functions where setup the trigger. Should that be done in this case also?

[hayesry]

Hey @Lunteer: Apologies for any confusion here, this was interpreted as a feature request for preventing non-image files from going through the image handler logic. If you're looking to use the same CloudFront URL to serve other content from a specific bucket, I would definitely recommend adding the needed behaviors as mentioned by @mattcrowe above. This is also a good approach since it bypasses the 6 MB response payload limit imposed by Lambda and allows for more fine-grained control of both file types and file sources going through the distribution. Hope this helps! Happy to chat out additional workarounds to this issue with you all.

[Lunteer]

@hayesry Thanks for the clarification. Newbie to all of this and not a developer by trade (figuring it out as I go along) so did get confused.
Another related question...
In our case our users can upload any (non program) files like word doc, excels, PDFs, etc. so we need to be very flexible. Is it not better to make the default have the origin as the S3 bucket and then write rules for each image type to point to the Lambda function?

Thanks!

[EricHe56]

@mattcrowe thank you for giving us a direction. Finally we use cloudfront function to sovled it as that aws path pattern is case sensitive and we have many types file need to add. it is hard to manually add all of types and all possible path patterns.
our solution is here:

1. create new distribution files.example.com => s3
2. create cloudfront function(redrict_doc_request). that redirect doc request to files.example.com
   *** add this function (redrict_doc_request as name) in your aws page => Cloudfront => Functions

function handler(event) {
    // redirect doc request to files domain
    var request = event.request;
    var headers = request.headers;
    var host = request.headers.host.value.replace("images", "files");
    var newurl = `https://${host}`+request.uri;
    
    // get extend name
    var extS = request.uri.split('.');
    var extName = extS[extS.length - 1].toLowerCase();
    var fileTypes = ['doc', 'docx', 'key', 'odt', 'pdf', 'ppt', 'pptx', 'pps', 'ppsx', 'xls', 'xlsx'];
    if (fileTypes.includes(extName)) {
        var response = {
            statusCode: 302,
            statusDescription: 'Found',
            headers:
                { "location": { "value": newurl } }
        }
        return response;
    }
    return request;
}

3. add cloudfront function (redrict_doc_request) in image.example.com's behavior - Default()
   a. select your distribution (image handler one) on aws page
   b. click Behaviors tab, then choose Default() line, then click edit btn.
   c. scroll down to the end, you will see 'Function associations - optional'
   d. for the 'Viewer request', Function type is 'CloudFront Functions', then Function ARN / Name is you added function name last step which should be 'redrict_doc_request'

then all done.

[Vadorequest]

For anyone else with this issue, you can add new Behavior/s in your Cloudfront distribution for other file types that use your s3 bucket/s as the Origin.

@mattcrowe I do not understand what to do exactly to achieve that result.

I did something similar but I must have missed something because my pdf urls are still displaying the same error.

[Vadorequest]

@EricHe56 Could you explain where you made those changes in the source code? In which file? Or is it directly done in CloudFront? (and if so, how?)

[EricHe56]

@EricHe56 Could you explain where you made those changes in the source code? In which file? Or is it directly done in CloudFront? (and if so, how?)

Thanks @Vadorequest , I have added more details for the post. hope that can helps. let me know if any questions.