Comments below. On Fri, Apr 7, 2023 at 4:16 AM Mario Loffredo <[email protected]> wrote: > > Hi Andy, > > Il 06/04/2023 16:36, Andrew Newton ha scritto: > > On Thu, Apr 6, 2023 at 9:56 AM Mario Loffredo<[email protected]> > > wrote: > >> [ML] Sorry for the delay in replying and thanks for this. > >> > >> Really there are some documents under discussion that would be > >> eventually affected. > >> > >> But I wonder where it's stated that query parameters should/must not be > >> preserved in redirections. > >> > >> Do you refer to a generally adopted practice or to an IETF document ? > >> > >> I took a look at RFC 9110 and didn't find specific statements about that. > > Because unless the server issuing the redirects explicitly preserves > > the query parameters in the new URL, they will not be preserved. My > > quick glance of 9110 does not say that query parameters are preserved > > so I don't know how a conclusion can be drawn that they are. But we > > don't have to be so theoretical about it. We can just try it: > > > > $ curl -vhttps://rdap-bootstrap.arin.net/bootstrap/autnum/2830?someparam=foo > > * Trying 199.212.0.160:443... > > * Connected to rdap-bootstrap.arin.net (199.212.0.160) port 443 (#0) > > * ALPN, offering h2 > > * ALPN, offering http/1.1 > > * successfully set certificate verify locations: > > * CAfile: /etc/ssl/cert.pem > > * CApath: none > > * (304) (OUT), TLS handshake, Client hello (1): > > * (304) (IN), TLS handshake, Server hello (2): > > * (304) (IN), TLS handshake, Unknown (8): > > * (304) (IN), TLS handshake, Certificate (11): > > * (304) (IN), TLS handshake, CERT verify (15): > > * (304) (IN), TLS handshake, Finished (20): > > * (304) (OUT), TLS handshake, Finished (20): > > * SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 > > * ALPN, server did not agree to a protocol > > * Server certificate: > > * subject: C=US; ST=Virginia; L=Chantilly; O=American Registry for > > Internet Numbers, Ltd.; CN=*.arin.net > > * start date: Aug 4 00:00:00 2022 GMT > > * expire date: Sep 4 23:59:59 2023 GMT > > * subjectAltName: host "rdap-bootstrap.arin.net" matched cert's > > "*.arin.net" > > * issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1 > > * SSL certificate verify ok. > >> GET /bootstrap/autnum/2830?someparam=foo HTTP/1.1 > >> Host: rdap-bootstrap.arin.net > >> User-Agent: curl/7.79.1 > >> Accept: */* > >> > > * Mark bundle as not supporting multiuse > > < HTTP/1.1 302 > > < Date: Thu, 06 Apr 2023 14:23:33 GMT > > < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips > > < Location:https://rdap.db.ripe.net/autnum/2830 > > < Content-Length: 0 > > < Access-Control-Allow-Origin: * > > < > > * Connection #0 to host rdap-bootstrap.arin.net left intact > > > > -andy > > [ML] AFAIU from RFC 9110, removing the query part from the target URI is > a misinterpretation of redirection . > > If the original target URI includes the query part, it should be > preserved in the new target URI similarly to the path part.
I'm not sure how such a conclusion can be made especially given current deployment of the technology does not support it. Furthermore, URI's are about identifying resources. RFC 3986 notes this about query parameters: "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)." A redirect indicates that one resource defined by a URI can be found by using another URI. Path and query help identify a resource and there is no defined preservation of either. What you want to do here is accept JSContact content instead of JCard content. That is content negotiation, and Section 12 of RFC 9110 clearly references the usage of HTTP headers for doing that. > > In addition, if I correctly understood RFC 7484 , the RDAP bootstrap > method consists in replacing only the base RDAP URL of the URI. RFC 7484 is silent on the subject as the purpose is to find the authoritative server. That said, the concept of redirect servers was well known at the time as they are mentioned in Section 8. There was even a draft specifically about them that never progressed (https://datatracker.ietf.org/doc/html/draft-ietf-weirds-redirects-04). Neither mention preservation of query parameters. Given this and current deployments of the technology, it is unsafe to assume that query parameter preservation is a common practice. Also, redirects in the RDAP ecosystem can be found beyond the bootstrapping system. For the purposes of this draft, it is probably best to drop the query parameters especially as they aren't needed to move the draft forward. -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
