coopernurse / caddy-awslambda Goto Github PK

View Code? Open in Web Editor NEW

45.0 45.0 4.0 36 KB

Caddy plugin that gateways requests to AWS Lambda

Home Page: https://caddyserver.com/docs/http.awslambda

License: MIT License

Go 97.36% Shell 1.30% Dockerfile 1.34%

caddy-awslambda's People

Stargazers

Watchers

Forkers

niilo nx-jackal lemonsn rzv-me

caddy-awslambda's Issues

Caddy's import path has changed

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.

header_upstream directive

Hi @coopernurse, neat plugin here!

It would be even neater if we could use the header_upstream directive in awslambda blocks, too!

Eg.: Currently there is no way to see the client ip inside a called lambda function. Something like:

header_upstream X-Real-IP {remote}

would solve this, I guess.

Or is there another way?

EDIT: I'm willing to offer my help with the implementation, but I'm only a "mediocre at best"-go-developer and need guidance 😀

Lambda not invoked

Trying caddy for the first time I suspect this might just a configuration issue

Here is my Caddyfile
localhost:2015
awslambda /api/ {
aws_region eu-west-1
aws_access abc
aws_secret 123
}

Caddy plugins are
https://caddyserver.com/download/linux/amd64?plugins=http.authz,http.awslambda,http.reauth&license=personal&telemetry=on

When I call localhost:2015/api/caddy-1, I get no response back. Lambda from the console return a valid response. Lambda is configured based on the example provided in the readme

malformed non-200 responses when caddy accepts http/2

with the following caddy (v0.11.0) config

https://foo.example.com {
  tls {
    // ...
  }

  awslambda / {
    aws_access [redacted]
    aws_secret [redacted]
    single lambdaFn
  }
}

and the following function (taken from the README with minor modification)

exports.handler = (evt, ctx, cb) => {
  var html, reply;
  html = '<html><head><title>Caddy Echo</title></head>' +
         '<body><h1>Request:</h1>' +
         '<pre>' + JSON.stringify(evt, null, 2) +
         '</pre></body></html>';
  reply = {
      'type': 'HTTPJSON-REP',
      'meta': {
          'status': evt.meta.path === '/error' ? 400 : 200,
          'headers': {
              'Content-Type': [ 'text/html' ]
          }
      },
      body: html
  };
  cb(null, reply);
}

When hitting a 200 path the response is OK, but when you hit /error and a 400 status code is returned (the same applies to any 4xx and a 500) then the response is appended with the status code e.g.400 Bad Request like so

❯ http -v https://foo.example.com/error
GET /error HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: foo.example.com
User-Agent: HTTPie/0.9.9



HTTP/1.1 400 Bad Request
Content-Length: 512
Content-Type: text/html
Date: Thu, 06 Sep 2018 08:33:31 GMT
Server: Caddy

<html><head><title>Caddy Echo</title></head><body><h1>Request:</h1><pre>{
  "type": "HTTPJSON-REQ",
  "meta": {
    "method": "GET",
    "path": "/error",
    "query": "",
    "host": "foo.example.com",
    "proto": "HTTP/1.1",
    "headers": {
      "accept": [
        "*/*"
      ],
      "accept-encoding": [
        "gzip, deflate"
      ],
      "connection": [
        "keep-alive"
      ],
      "user-agent": [
        "HTTPie/0.9.9"
      ]
    }
  },
  "body": ""
}</pre></body></html>400 Bad Request

This is only happening when caddy accepts http/2 (but the request itself can be http/1.1 as shown above), but when http/2 is completely disabled with the following everything works fine.

  tls {
    alpn http/1.1
    // ...
  }

This appending happens during caddy responding, it's not coming from the lambda response envelope.

Path params not working

Path parameters are not possible given the current parsing code..

// ParseFunction returns the fragment of path that occurs after
// the last '/' character, excluding query string and named anchors.

Instead of the 'last', I think you should use the first part of the path after the matching route.

For example.. using the config..

awslambda /api/ {

The path /api/dogs/rex should return the function name 'dogs' and not the name 'rex' ... this would enable path parameters to work properly. Not sure the value of returning the last part of the path.

Add awslambda to the new Caddy website

Hey @coopernurse - I just wanted to reach out, I'm not sure if my email got through. There's a new Caddy website in staging that you should add the awslambda plugin to, so that people will be able to download and use it after April 20! People like it, someone just tweeted it the other day: https://twitter.com/pahudnet/status/850353283680026624

Let me know how to send you the link privately. :) The new website will allow you to manage your own releases and such, so it won't depend on me updating the build server manually, etc. I really want to get your plugin on the new site! 👍

coopernurse / caddy-awslambda Goto Github PK

caddy-awslambda's People

Stargazers

Watchers

Forkers

caddy-awslambda's Issues

Caddy's import path has changed

header_upstream directive

Lambda not invoked

malformed non-200 responses when caddy accepts http/2

Path params not working

Add awslambda to the new Caddy website

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent