> -----Original Message-----
> From: Gavin Brown <gavin.br...@icann.org>
> Sent: Thursday, August 14, 2025 12:27 PM
> To: Hollenbeck, Scott <shollenb...@verisign.com>
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [Ext] request for adoption: draft-brown-rdap-referrals
>
> Caution: This email originated from outside the organization. Do not click
> links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
> Hi Scott,
>
> My naive assumption is that an approach that leverages lower-level features of
> HTTP is likely to perform better than something higher in the stack. However,
> I
> am not wedded to that approach, and the WG (including yourself) may have a
> better idea.
[SAH] There may be programming language peculiarities here, but with PHP at
least there isn't much difference in the number of steps required to access the
information. Here's what one needs to do to process the HTTP headers associated
with an existing connection:
// Retrieve HTTP headers into an array.
$headers = getallheaders();
// Loop through the array to find the header we're looking for.
foreach ($headers as $key => $val) {
if (strcasecmp($key, "headerImLookingFor") == 0) {
// Process the value of the header.
}
}
...and the HTTP body:
// Read the raw HTTP request body into an associative array.
$rawBody = file_get_contents('php://input');
// Decode the JSON data into an associate array.
$data = json_decode($rawBody, true);
// Access the needed data element in the array.
$thingIWant = $data['keyImLookingFor'];
Decoding a large body may "cost" more than looping over a smaller number of
headers. Complexity-wise, I don't see a clear advantage to one approach over
the other.
> I think the objective of an efficient RDAP referral mechanism is more
> important
> than how it's implemented.
[SAH] Agreed, but why have two mechanisms? Do others see an advantage in
returning link information in the headers as opposed to returning that
information in the body? If so, what's the advantage?
> RFC 8982 may or may not provide the model, but we will need a document in
> either case. If the WG adopts this document, it can be developed with the
> input
> and guidance of the WG.
[SAH] We already have a document in 8982. I'd like to understand if this draft
solves a problem that isn't solved by 8982.
Scott
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
