Add Accept header to curl commands in traffic docs

[tomastauber-da]

ported from canton-network/splice#4298

[Jatinp26]

@tomastauber-da did the debug on variable validation on the current changes, it seems to fail in MDX Page currently being in the commit with the changes. Basically, the committed synchronizer-traffic.mdx no longer matches what the generator produces.

Could you please update the forked branch based on current content on main and then redit your content and make a new commit @tomastauber-da ?

Below is the specific error debug log block from the failed job outta the above check.

> python3 scripts/validate_network_variable_tabs.py
Network variable tabs are stale. Run `npm run generate:network-variable-tabs` and commit the rendered MDX changes.
Updated 1 page(s).
 M docs-main/global-synchronizer/deployment/synchronizer-traffic.mdx
Error: Process completed with exit code 1
```.

[tomastauber-da]

@Jatinp26 it should be fixed now

[shreyas-da]

@martinflorian-da since you were reviewing this originally, would you mind reviewing here please?

[martinflorian-da]

Sure! @tomastauber-da I validated that the curl works both with and without your changes.

I assume you're opening this because it didn't work for you without the extra --header?

Would be curious to understand this a bit better before approving.

Specifically, how is it that --header "Content-Type: application/json" does not imply --header "Accept: application/json"?

I tested against https://scan.sv-1.dev.global.canton.network.sync.global/api/scan/v0/amulet-rules using two different curl versions.

> curl --version
curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.2 zlib/1.3.2 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.22.1 nghttp3/1.15.0 mit-krb5/1.22.1
Release-Date: 2026-04-29
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

> curl --version
curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.10
Release-Date: 2023-12-06, security patched: 8.5.0-2ubuntu10.13
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

[tomastauber-da]

@martinflorian-da previously, it didn't work without the header, but I haven't verified it in the recent versions

[martinflorian-da]

@martinflorian-da previously, it didn't work without the header, but I haven't verified it in the recent versions

That doesn't sound to me like confirmation enough that the problem exist to warrant merging a fix for it? As a frequent user of long curl commands I do enjoy them being not longer than they need to be :)

[martinflorian-da]

@tomastauber-da I would also be curious to know the affected version of curl. It sounds much more like a curl (and/or OS) issue than a scan issue.

[tomastauber-da]

@martinflorian-da I tried with curl 8.7.1, and it works without the explicit Accept header. So I think this can be closed