Creating a viewer-request Edge Lambda function to handle other formats.

[vchettur]

I have setup cloudfront serverless-iiif to accept .jpg requests in the resolver template. However, I want to also process occasional requests for .tif. As advised by @mbklein , one of our devs created an Edge Lambda function. Unfortunately, it returns an Unknown Error. If someone can comment on what changes are needed to make it work, it would be greatly appreciated. Perhaps, we are not reading the event correctly.

def lambda_handler(event, context):
    request = event['Records'][0]['cf']['request']
    headers = request['headers']
 
    # Check if the file has a .tif extension
    if request['uri'].endswith('.tif'):
        # Add the custom header to the request
        headers['x-preflight-location'] =  [{'key': 'X-Preflight-Location', 'value': 's3://prsv-api-s3access-ziyfhgdie8ao/denis/e011743086.tif'}]
        headers['access-control-allow-origin'] = [{'key': 'Access-Control-Allow-Origin', 'value': "*"}]
        headers['access-control-allow-headers'] = [{'key': 'Access-Control-Allow-Headers', 'value': "*"}]
        headers['access-control-allow-methods'] = [{'key': 'Access-Control-Allow-Methods', 'value': "OPTIONS, GET, POST, PUT, PATCH, DELETE"}]
        headers['access-control-max-age'] = [{'key': 'Access-Control-Max-Age', 'value': "86400"}]
 
    return request

In this example, we just uploaded e011743086.tif to the denis folder of the S3 bucket and tried to retrieve it via a Cloudfront URL in the standard IIIF URL format.

[mbklein]

I'm not totally clear on the use case you're describing. The extension at the end of the URI is used to determine the output format of the derived image, not the extension of the source image. For example, in the default configuration, if I request:

https://iiif.example.edu/iii/2/12345-67890/square/pct:80/0/default.jpg

serverless-iiif is going to do the following:

1. look for a source file called 12345-67890.tif in my source bucket
2. crop it square
3. resize it to 80%
4. return the manipulated image as a JPEG

https://iiif.example.edu/iii/2/12345-67890/square/pct:80/0/default.tif will do the same, but return the resulting image as a TIFF.

Step 1 above is what the resolver template is used for. With its default value %s.tif, it simply takes the ID of the requested image from the middle of the URL, adds .tif, and looks for that file in the root of the configured S3 bucket. A preflight function that adds an x-preflight-location header overrides this behavior and provides a specific location for the source image. But it still processes that source image into whatever output format is specified by the extension at the end of the request URL.

It sounds like in your case, most of your source images are JPEG but some are TIFF. Your preflight function will need to parse the URL to get the requested image ID, figure out the source location for the image identified by that ID, and put it in the x-preflight-location header. serverless-iiif will then use that image to create whatever output format is requested.

It looks to me like you are reading the event correctly, but I noticed one other issue with your lambda function: The CORS headers (access-control-*) need to be part of the response, not passed through as part of the request. If you need to customize them per request, you'd need to use a separate Lambda@Edge function attached to the viewer-response hook.

Is there anything specific about the error in your lambda function CloudWatch logs? It can be tricky to find the right log for a Lambda@Edge function – the log itself is stored in the CloudWatch region where the function was invoked, not where it was deployed, but the log name includes the region where the function is deployed.

For example, I have a IIIF server deployed in the us-east-1 region. But since I myself am in the Chicago area, when I make a request, it's handled by CloudFront in the us-east-2 region. So for my lambda function called iiif-preflight, I have to look in us-east-2 for a log group called /aws/lambda/us-east-1.iiif-preflight to find the log with my requests in it.

One last thought: is prsv-api-s3access-ziyfhgdie8ao the bucket you entered when you deployed serverless-iiif? If so, the lambda function was given read permission and everything should be fine with access. But if this is a special case where you're pointing serverless-iiif to a different bucket than the one it was configured with, you'll need to make sure the lambda function has read access to that bucket and its contents as well.

[vchettur]

Yes. There may be instances where the user may request a .tif file from our API service which retrieves assets from Preservica and copies it to the S3 bucket to which serverless-iiif is configured.

Since I configured the resolver template as %s.jpg since we automatically create .jpg copies from the .tif at the time of ingest to Preservica and those are the files that get normally get transferred. It will currently ignore any .tif requests.

I need some way to handle any odd requests for .tif or for special projects in the future and you had suggested looking into Edge Lambda. I will double check all the settings again.

Regards, Vinod

[mbklein]

OK, I think I understand better.

Just to be clear, serverless-iiif never simply reads the file from S3 and returns it to the user, no matter what format it's in. It's whole purpose is to create derivative images (cropped, resized, rotated, and/or transcoded to a different format) using the images stored in S3 as a source.

[vchettur]

@mbklein I do understand that. I'm implementing as forward looking functionality since there's a lot of investment in high-end large format scanning of paintings, coin collections, and maps that are currently stored on LTO tapes. So while at the moment, we need only basic image delivery using the Presentation API, adding the capability will open doors for the institution.

[mbklein]

Great to hear. I apologize if I was being overly pedantic; I find that people come to this project with different ideas of what it will or will not do for them, so I like to be sure.

[vchettur]

Not at all. What has been achieved in your project is great balance between performance and light-weight implementation. It performs wonderfully well even now when we deliver compound digitized objects like the 1931 Census Form booklets.