You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My goal here is to make it easier to implement serverless-sharp within another serverless application. One could load load the serverless-sharp handler on a different function path as detailed in #71, but that doesn't address the scenario detailed in #72, where one may desire different error handling on missing files or different handler of unsupported file types.
This approach is an attempt to address both scenarios. And it almost works.
serverless-http should automatically handle binary data based on supported content_type and that appears to be the case. The only problem is that it renders a broken image. Interestingly, when inspecting the response payload the file size is larger than when using the normal handler for the same image, which leads me to believe the image is perhaps being double encoded? Perhaps, someone has a better idea than me as to what is happening here.
The text was updated successfully, but these errors were encountered:
Oh, one minor additional issue is that the handler cannot be used in an async function, and must be provided with a succeed callback, preventing the use of the handler in a chained middleware. This could be resolved by updating the handler function to test if the success callback exists and otherwise return the result directly.
In attempting to resolve #72 and #71, I have developed the following approach of using the serverless-sharp handler as serverless-http koa middleware.
My goal here is to make it easier to implement serverless-sharp within another serverless application. One could load load the serverless-sharp handler on a different function path as detailed in #71, but that doesn't address the scenario detailed in #72, where one may desire different error handling on missing files or different handler of unsupported file types.
This approach is an attempt to address both scenarios. And it almost works.
serverless-http should automatically handle binary data based on supported content_type and that appears to be the case. The only problem is that it renders a broken image. Interestingly, when inspecting the response payload the file size is larger than when using the normal handler for the same image, which leads me to believe the image is perhaps being double encoded? Perhaps, someone has a better idea than me as to what is happening here.
The text was updated successfully, but these errors were encountered: