Hi Tom, On 7/9/26 11:52 PM, Tom Harrison wrote: >>> This is not a good idea. While it seems to work on paper, it does >>> not work well in practice. If you `curl ... | jq` the data piped is >>> the content from the redirect. jq never sees the content in the >>> redirect. > > This is true for "curl -L" (i.e. "follow redirects"), but by default > curl will just return the redirect body, so at least in the somewhat > unusual case of a motivated user who has access only to curl, it's > possible for them to see that content.
It is not an issue of motivation. I pointed out the curl use case because it was easy to demonstrate, but for RDAP clients running in a browser, which are many and popular, this is a big outright limitation. Using the fetch API, you can switch the processing to manual to detect the redirect but you cannot get the content. https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect An opaque-redirect filtered response is a filtered response whose type is "opaqueredirect", status is 0, status message is the empty byte sequence, header list is « », **body is null**, and body info is a new response body info. > > More relevantly, though, RDAP itself (per earlier comments, and at > least as far as IP resources are concerned) is primarily about sending > to the client the most-specific available resource. Optimising for > that use case seems sensible, particularly when the alternative > approach will require client software updates merely to maintain > existing expectations around response handling. As Kaveh pointed out, there is an authority boundary being crossed. That is an important distinction. I do realize that the RIRs use redirects to deal with transferred resources, and that is technically a cross-boundary redirect. Maybe that wasn't a wise decision in hindsight... And it is probably my fault as I likely was the one who suggested it. Not that the behavior should change now (water under the bridge), but there is a split personality thing going on with the RFC 9082 ip lookup and the RFC 9910 searches, which apparently are not suppose to cross boundaries (sensible for down and bottom, but what about up and top). Perhaps the solution is the counter to the redirects extension... a no_redirects extension. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
