413/414 Request URL/Entity Too Large Error Nginx

413/414 Request URL/Entity Too Large Error Nginx

what is 413/414 request URL/entity too large issue?


Ever tried to upload a huge file or send a very large payload in the request?


If yes, you must have received status code 413 from nginx saying that the “request entity is too large for nginx to handle”.

The reason for this error response is because of the “client_max_body_size” parameter in the nginx configuration.

Web servers keep a limit on the maximum size of the request that can be sent to them. This is handled using client_max_body_size parameter. That is because, as mentioned in this stack exchange answer and I quote —

If you configure “client_body_max_size" to a large value, then you are putting your server in the same scenario as by 2013 when Django allowed users to use a very long password forcing Django (rather the server where it is hosted) to perform very expensive hash calculations leading, as you may guess, to a denial-of-service attack against the whole Django’s authentication framework.

In nginx documentation, By default, the value client_body_max_sizeis 1 MiB.

If it is a requirement to change client_body_max_size in nginx configuration, It can be done in the following way:

  • Run the following command to editnginx.conf the file.


vi /etc/nginx/nginx.conf


  • Add the following line at the top of httpserver or location context to edit the size and then save and close the file.


client_max_body_size 10M;


  • Restart nginx using the following command.


sudo service nginx restart


There you go, the maximum permitted request size in nginx configuration has been changed.

HTTP 414 request-URI too large



I encountered this error while working on Open-Source project in elixir— Avia Commerce.


The HTTP 414 URI Too Long response status code indicates that the URI requested by the client is longer than the server is willing to interpret.


Talking in terms of “Nginx” web server. This can also be handled in a similar manner as HTTP 413 error. To handle this we have to modify large_client_header_buffers parameter in the server configuration.

As mentioned in the documentation, the default size of 


large_client_header_buffers is 8 KB.


This way you errors pertaining to max size of request payload or request URI can be handled.


About RemotePanda

RemotePanda is a personalized platform for companies to hire remote talent and get the quality work delivered from the city Pune. The resources in our talent pool are our close network connections. While connecting them with you, we make sure to manage the quality, growth, legalities, and the delivery of their work. The idea is to make remote work successful for you. Get in touch with us to learn why RemotePanda is the best fit solution for your business requirements.


5 Best Strategies to Reduce your AWS billing & Monthly Save Up to $1000 +

5 Best Strategies to Reduce your AWS billing & Monthly Save Up to $1000 +


Save 1000$+ monthly on your AWS Bill with these Simple Hacks


Recently I did a short video on how to bring your AWS billing down by more than 80%, which went quite viral on the internet achieving thousands of impressions within a day. It made me realize that there are many founders/CXOs who face this issue of the high bill on AWS or any similar cloud platform. This post is a further extension on the points I mentioned in the video and provides additional ways on how you can save money on AWS.


1. Selecting the appropriate size for the AWS server –



It is crucial for every organization to choose the correct size of the server. At the initial stage of your startup, it is advised to start with a small server. Apart from that setting up auto-scaling really helps. Auto-scaling option continuously scales the servers dynamically based on the traffic. This means that your server will scale up and down automatically based on the traffic on your website, so you don’t need to pay for a big dedicated server.


2. Using S3 + CloudFront instead of EC2 –



Many people use EC2 servers for hosting their website. If you use static or dynamic website go for the S3 + CloudFront option instead of EC2 as it is more scalable and more secure as well as it costs less. Instead of paying for the dedicated EC2 server you can go for the cheaper S3 + CloudFront option.


3. Terminate development and QA environment when not required –


A simple trick to reduce the cost is to turn-off the development and QA environment on weekends and holidays when no one is using them. You can easily setup Lambda function which triggers the turning on and off of the servers. Just by applying this you can save up to 50% of the cost whenever you are not using it.

We also apply this facility to many of our clients. When our working hours are done, and on weekends when no one is using the service, the servers shut down automatically.


4. Use AWS Reserved Instances –


Another great thing about AWS is that it offers the ability to reserve instances. Suppose you scored a great project whose duration is going to be around one year and you know what all instances you will need from the AWS. In this case, you can reserve the required instances with AWS. All you need to do is tell Amazon that you will require these instances for one year and Amazon brings down the cost for those instances.


5. Using the complete AWS features optimally –


Have you heard of SSL certificate? An SSL Certificate is essentially a digital certificate that authenticates the identity of a website and encrypts information sent to the server using SSL technology.

Many of our clients buy SSL certificate from GoDaddy or any other providers, they have to pay a considerable amount for it, but AWS on the other side provides SSL certificate for free if you set it up correctly. So with AWS, you don’t have to worry about buying an SSL certificate, moreover at the time of renewal and again setting it up AWS takes care of it all.




I am sure that by applying these best practices you can also save a few extra bucks just like we did. Also, feel free to connect with me if you want to discuss or want me to look into your AWS instance, I’d be more than happy to help. I can be reached on pravin@startupgrind.com

A Quick Overview of HTTP Methods

A Quick Overview of HTTP Methods

a quick overview of http methods

HTTP is the language of the web. If you’ve ever been involved in developing or communicating with a web server, chances are that you’ve been using HTTP.

HTTP is a server-client protocol. All communication is initiated by the client, in the form of an HTTP request. On receiving this request, the server sends an HTTP response back to the client.

Here is an excellent overview of HTTP that covers the structure of communication over HTTP— https://www.jmarshall.com/easy/http/

A simple HTTP request to fetch posts from a server could look like this –

GET /posts HTTP/1.1


The first part, GET is the HTTP method. The second part/posts are the URI. The third partHTTP/1.1 is the HTTP version.


The HTTP method indicates the action we wish to perform, and the URI indicates the resource that we want to perform the operation on.


The HTTP specification defines these methods – GET, POST, PUT, HEAD, DELETE, OPTIONS and a few more.



GET requests are used to retrieve information about the resource specified by the URI. GET is a safe method — that means a GET request should not result in any changes in the server state. It should not cause creation, updating or deletion of any application data. It should be used only for ‘read-only’ actions.



POST requests are used to submit data to the server. POST requests may contain a data payload to be submitted to the server. The action performed by the server is determined by the server code. POST requests may be used to create a new resource or to submit data for processing.



PUT requests are used to save an object at the location specified in the request URI. PUT requests should be idempotent. That means that if two or more identical PUT requests are received and executed, the result should be equivalent to executing such a request only once. 

To draw an analogy, a=5 is an idempotent operation since running it once or multiple times results in the value of a being 5. In contrast, a=a+1 is not an idempotent operation, since the value of changes based on how many times we execute the operation.



DELETE requests are used to delete the object at the location specified in the request URI. DELETE requests are also idempotent.



HEAD requests are used to retrieve just the headers that would be present in the response of an equivalent GET call. It could be used simply to check whether or not a resource exists or to retrieve the Content-Length Header before deciding whether or not to download a large file. You could also check the Last-Modified header to see if the file was modified since you last retrieved it. The HEAD method is safe. All safe methods are also idempotent since doing nothing once has the same effect as doing nothing multiple times.


Not all POST methods need to be unsafe. We had a case where we needed to send a large number of email addresses to the server and respond with a yes or no for each of those addresses. It seemed like a GET request at first, but we discovered that some browsers and proxies limit the length of a GET request. It also started feeling more like the URI pointed to a processing service and not to an object, and that it would be fine to POST a list for processing.

To know more about client-server protocol or want to hire a back-end Developer you can contact RemotePanda.