Originally posted on my blog
Elastic Beanstalk is great! It is very easy to get a Rails app up and running on AWS quickly. Perfect for an app deve...
For further actions, you may consider blocking this person and/or reporting abuse
I think there is probably small issue with this setup. I think returning redirect is correct behavior for GET and HEAD requests but for other methods I believe the correct behavior would be to return 405 Method Not Allowed (or 307).
It's probably not a big deal in practice but returning redirect on other methods is not correct according to HTTP specification.
Interesting, I had not considered that. Like I said, the content of the NginX config is from awsdocs so I didn't question this directive since it did what I wanted it to.
As you say, probably not a big deal, but to be more compliant to the spec, maybe something like this would be a better approach.
Cause I can't see a scenario where you would need it for anything other than GET or HEAD.
Edit: Or maybe the uri is not needed when returning 405... Will have to check the specs in more detail.
AWS ALB should support redirections from HTTP to HTTPS, according to this blog post:
aws.amazon.com/about-aws/whats-new...
Yes, I've seen that the Elastic Load Balancer should be able to handle this. What I believe is the issue is that the configuration options in Elastic Beanstalk is not giving you the full interface that is available for the Load Balancer. So if you would go through EC2 > Load Balancer and manually configure it there, it would probably (I am not 100% on this) reset it in future deploys.
This is I believe one of the trade offs that you get when using the "easy" option of Elastic Beanstalk.
Once again, I can not guarantee this, but in my experience, anything that you configure outside of the EB interface, will get reset sooner or later. Unlike the configurations you apply through .ebextensions that will always be reapplied on deployments.
That issue could be reported to AWS support. As you said, redirecting from HTTP to HTTPS has become an ordinary requirement.
Also, this kind of limitation is a signal that you should move to CloudFormation or Terraform to deploy your stack.
True, reporting it is a good idea. I have recently seen that several people at AWSCloud are reaching out to request feedback on missing features for their respective products, so might be a good time.