Skip to content

REST API incorrectly uses charset parameter in application/json Content-Type #10500

@Jayman2000

Description

@Jayman2000

What happened?

Some of Syncthing’s REST API’s endpoints return JSON data. When the Syncthing REST API returns that data, it uses application/json; charset=utf-8 as the data’s Content-Type. The charset parameter should not be used with application/json media types. The IANA media type registration template for application/json says:

Type name:  application

Subtype name:  json

Required parameters:  n/a

Optional parameters:  n/a

Encoding considerations:  binary

Security considerations:  See RFC 8259, Section 12.

Interoperability considerations:  Described in this document

Published specification:  RFC 8259

[…]

Note:  No "charset" parameter is defined for this registration.
   Adding one really has no effect on compliant recipients.

Even if a charset parameter was allowed, it would be unnecessary. Section 8.1 RFC 8259 says:

   JSON text exchanged between systems that are not part of a closed
   ecosystem MUST be encoded using UTF-8 [RFC3629].

Syncthing and the consumers of its REST API are definitely not a part of a closed ecosystem which means that all of the JSON text produced by Syncthing’s REST API has to use UTF-8 anyway. Even if Syncthing and the consumers of its REST API were a part of a closed ecosystem, it would probably be best to just use UTF-8 for all JSON text anyway.

Steps to reproduce

  1. Make sure that Syncthing is running that that the GUI/REST API is enabled.

  2. Use the Syncthing REST API by running this command:

    curl --verbose http://<GUI/REST API address>/rest/noauth/health

Syncthing version

v2.0.13-dev.10.g801ef0e2

Platform & operating system

NixOS 25.11x86_64

Browser version

No response

Relevant log output

* Host localhost:8384 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0*   Trying [::1]:8384...
* connect to ::1 port 8384 from ::1 port 45004 failed: Connection refused
*   Trying 127.0.0.1:8384...
* Established connection to localhost (127.0.0.1 port 8384) from 127.0.0.1 port 55096 
* using HTTP/1.x
> GET /rest/noauth/health HTTP/1.1
> Host: localhost:8384
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Cache-Control: max-age=0, no-cache, no-store
< Content-Type: application/json; charset=utf-8
< Expires: Fri, 19 Dec 2025 22:21:01 GMT
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Syncthing-Id: DCIKYG6-ZLIXZ6F-Z6O4TVY-YE2QJBA-4GAFC3A-I2FYK7W-7DW766Q-S7IG2AM
< X-Syncthing-Version: unknown-dev
< X-Xss-Protection: 1; mode=block
< Date: Fri, 19 Dec 2025 22:21:01 GMT
< Content-Length: 21
< 
{ [21 bytes data]
100    21 100    21   0     0  8433     0  --:--:-- --:--:-- --:--:-- 10500
* Connection #0 to host localhost:8384 left intact
{
  "status": "OK"
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugA problem with current functionality, as opposed to missing functionality (enhancement)needs-triageNew issues needed to be validated

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions