Sync Gateway PUT Bad JSON Error

Mobile Sync Gateway
1

I am attempting to configure my sync gateway via curl, but the following command gives me an error:

/bin/curl -v --location --request PUT 'http://localhost:4985/myscope/_config/' \
  --user "$AUTHUSER" \
  --header 'Content-Type: application/json' \
  --data-raw '{ "enable_shared_bucket_access": true, "import_docs": true }'

The error I receive:

< HTTP/1.1 400 Bad Request
sync-gateway      | < Content-Type: application/json
sync-gateway      | < Server: Couchbase Sync Gateway/3.2.1 EE
sync-gateway      | < Date: Thu, 02 Jan 2025 20:42:53 GMT
sync-gateway      | < Content-Length: 48
sync-gateway      | <
sync-gateway      | * Connection #0 to host localhost left intact
sync-gateway      | {"error":"Bad Request","reason":"Bad JSON: EOF"}

Even when I send empty brackets I get the same error.

However my other curl requests are working fine:

/bin/curl --location --request PUT 'http://localhost:4985/myscope/' \
  --user "$AUTHUSER" \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "bucket": "mybucket",
    "num_index_replicas": 0,
    "scopes": {
      "myscope": {
        "collections": {
          "mycollection":{
          }
        }
      }
    }
  }'

What am I doing wrong in my curl commands?

2

Hi @chrisdovi, probably the issue is that you’re updating the database configuration with a “PUT” curl command.
The PUT is usually used to create the database and requires specific fields.

The “POST” curl command instead is used to update only the fields that you specify in your data.
Give it a try and let me know if it works :wink:

3

@fabiosst Changing to POST gives me the same error:

Connected to localhost (127.0.0.1) port 4985 (#0)
sync-gateway      | * Server auth using Basic with user 'sync'
sync-gateway      | > POST /myscope/_config/ HTTP/1.1
sync-gateway      | > Host: localhost:4985
sync-gateway      | > Authorization: Basic c...=
sync-gateway      | > User-Agent: curl/7.81.0
sync-gateway      | > Accept: */*
sync-gateway      | > Content-Type: application/json
sync-gateway      | > Content-Length: 60
sync-gateway      | >
sync-gateway      | * Mark bundle as not supporting multiuse
sync-gateway      | < HTTP/1.1 301 Moved Permanently
sync-gateway      | < Location: /myscope/_config
sync-gateway      | < Date: Fri, 03 Jan 2025 14:45:13 GMT
sync-gateway      | < Content-Length: 0
sync-gateway      | <
sync-gateway      | * Connection #0 to host localhost left intact
sync-gateway      | * Issue another request to this URL: 'http://sync:P...c@localhost:4985/myscope/_config'
sync-gateway      | * Switch from POST to GET
sync-gateway      | * Found bundle for host localhost: 0x5638ca862010 [serially]
sync-gateway      | * Can not multiplex, even if we wanted to!
sync-gateway      | * Re-using existing connection! (#0) with host localhost
sync-gateway      | * Connected to localhost (127.0.0.1) port 4985 (#0)
sync-gateway      | * Server auth using Basic with user 'sync'
sync-gateway      | > POST /myscope/_config HTTP/1.1
sync-gateway      | > Host: localhost:4985
sync-gateway      | > Authorization: Basic c...=
sync-gateway      | > User-Agent: curl/7.81.0
sync-gateway      | > Accept: */*
sync-gateway      | > Content-Type: application/json
sync-gateway      | >
sync-gateway      | * Mark bundle as not supporting multiuse
sync-gateway      | < HTTP/1.1 400 Bad Request
sync-gateway      | < Content-Type: application/json
sync-gateway      | < Server: Couchbase Sync Gateway/3.2.1 EE
sync-gateway      | < Date: Fri, 03 Jan 2025 14:45:13 GMT
sync-gateway      | < Content-Length: 48
sync-gateway      | <
sync-gateway      | * Connection #0 to host localhost left intact
sync-gateway      | {"error":"Bad Request","reason":"Bad JSON: EOF"}
4

You’re adding a trailing slash “/” at the end of the curl endpoint.

Right now you’re receiving a 301 response, which is a redirection and then a 400 error since the data is not redirected.

Try calling the “…/db/_config” endpoint, without ending slash.
Then it should work.

5

That worked, trailing slash was forcing redirect. Makes sense why the Content-Length was decreasing after the redirect.

1 Like
6

Nice to hear that!

Yes, the main reason is that, after the redirection, the curl command switches from a POST call to GET a call.
Hence, no data is passed with a GET call.