Search code examples
jsonnginxkuberneteskubernetes-helmnginx-ingress

Custom JSON file created by Kubernetes-Helm gets cut off when curling/browsing to it

I am new to the whole Kubernetes-Helm thing, please bear with me and I'll try to give as much clarity to my question as possible

So I have this ConfigMap.yaml file that does this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: envread-settings
  namespace: {{ .Values.environment.namespace }}
data:
  appsettings.environment.json: |-
    {
      "featureBranch": {{ .Values.component.vars.featureId | quote }},
      "BFFServiceUrl": {{ .Values.environment.BFFServiceUrl | quote }}
    }
---

Where the Values are:

  • .Values.component.vars.featureId = 123
  • .Values.environment.BFFServiceUrl = api.dev.integrations/bff-service

This creates an appsettings.environment.json file in a volume path I specified. I need to dynamically create this json file because I need to insert the above variables in there (can't use environment variables sadly for my app).

When I ssh into the terminal and vim everything looks dandy on that file i.e:

{
   "featureBranch": "123",
   "BFFServiceUrl": "api.dev.integration/bff-service"
}

But when I curl this file I get:

{
   "featureBranch": "123",

and the same can be said when I browse directly to this file (I am running an Angular SPA app using ASP.NET Core 3.1).

Is there something horribly wrong I am doing in the yaml file?

Edit The curl command that I am running is: curl https://api.integrations.portal/assets/appsettings.json. There is a NGINX Ingress running in between the request and response.

Solution

  • I used to have a similar problem. In my case, curl returned error code 18. You can check this for yourself by running your curl and then echo $?. As I mentioned I had error code 18 which means:

    CURLE_PARTIAL_FILE (18) A file transfer was shorter or larger than expected. This happens when the server first reports an expected transfer size, and then delivers data that doesn't match the previously given size.

    Here you will find a link to the description of any errors that curl may return. In case you get another error.

    This seems to be a server side issue. You might try to work it around by forcing HTTP 1.0 connection (to avoid chunked transfer which might cause this problem) with the --http1.0 option.

    Additionally, if you have a Reverse Proxy or Load Balancer using Nginx and your /var (or your partition where Nginx logging happens) is full, Nginx's server response might be cut off.

    You can also read this question.