Hi Jim, > I mirror the other feedback with the concern over duplicating the link > information in the response header that is included in the response body for > the HTTP GET. It would be best just to support the HTTP HEAD.
The reason why the link headers are included in the GET response is because the HTTP specification says that for the same resource, the headers have to be the same for both HEAD and GET. So to get them in the HEAD response (which is where they bring benefit) they have to be present in the GET response. > the question I have is whether the use of the HTTP HEAD is appropriate, where > in RFC 7480 the HTTP HEAD is meant to determine the existence of data on the > server and not meant to be used as a form of filtering. I don't see anything normative in RFC 7480 that prevents the HEAD request from being used for other purposes. I also don't believe this counts as "filtering" of any kind. > How about creating an RDAP extension that defines a query parameter that can > be used for selecting / filtering of information to include in the response, > where in this case all that the client desires is the "links" information? > Keep the information in the response body and enable the client to specify > the set of data desired, which can be leveraged for additional forms of > selection to reduce client/server overhead and network bandwidth. That would be another approach. G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
