From f1ee4aeef75b7f6a00b66a42e09b1d8e06b4f35d Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Thu, 16 Oct 2025 18:33:48 -0700 Subject: [PATCH] Make `DNS-error-payload` just contain a string. Having `DNS-error-payload` record contain a string field for `rcode` while a `u16` field for `info-code` is surprising. If appplications will be expected to know the IANA values of the `u16` [INFO-CODE value], it would make sense for them to know the `u16` for the [RCODE value] too. But if they won't, then they likely don't have any use for either `u16` value, and just want a simple string. I think wasi-http could plausibly go either way: Provide `u16` values for both `rcode` and `info-code`, or neither, and instead just provide a `string`. In this PR, I propose to just provide a `string`. My guess is that most applications in scope here don't need precise DNS error code information and basically just need a way to report that "it was DNS". And, not all host resolver libraries provide error information that includes RCODE and INFO-CODE, for example [Rust's `ToSocketAddrs` trait] or [POSIX `getaddrinfo`]. Fixed #184. [RCODE value]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 [INFO-CODE value]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes [Rust's `ToSocketAddrs` trait]: https://doc.rust-lang.org/stable/std/net/trait.ToSocketAddrs.html [POSIX `getaddrinfo`]: https://pubs.opengroup.org/onlinepubs/9799919799/functions/freeaddrinfo.html --- wit-0.3.0-draft/types.wit | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/wit-0.3.0-draft/types.wit b/wit-0.3.0-draft/types.wit index 0f0e838..95d4db2 100644 --- a/wit-0.3.0-draft/types.wit +++ b/wit-0.3.0-draft/types.wit @@ -75,8 +75,10 @@ interface types { /// Defines the case payload type for `DNS-error` above: record DNS-error-payload { - rcode: option, - info-code: option + /// An indication of the reason for the DNS error, if known. + /// + /// This string is meant only for human consumption, and not for machine parsing. + reason: option, } /// Defines the case payload type for `TLS-alert-received` above: