Subject: [urn] q-component: What happens if the URL resolved to already has a query component?

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 21 Dec 2016 11:56:04 +0000

All,

This might be dealt with already, so please bear with me if I repeat an old discussion...

In §2.3.2 the following is said about the q-component (modulo Peter's proposed changes):

[[
The URN q-component has the same syntax as the URI query component, but is introduced by "?=", not "?" alone. For URNs that may be resolved to a URL, the semantics of the q-component are identical to those for the query component of that URL. Thus URN resolvers returning a URL for a URN with a q-component do this by copying the q-component from the URN to the query component of the URL. It the URN does not resolve to a URL, the interpretation of the q-component is undefined by this specification. An example of the copying operation appears below.
]]

This leaves the question open, what will happen if a URN with a q-component resolves to a URL that already has a query component. My take is that that case is outside the scope of 2141bis, but I think we should be explicit about that and suggest that we add some text along the following lines:

[[
It is possible that a URN with a q-component resolve to a URL that already has a query component. In that case, the final URL will end up having a query component consisting of the URL's original query component and the q-component from the URN. If the new query component makes sense is outside the scope of this specification.
]]

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49 69 1525-1752
Telefax: +49 69 1525-1799
mailto:[email-masked] 
http://www.dnb.de

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Dec 2016 13:42:48 -0700

On 12/21/16 4:56 AM, Svensson, Lars wrote:
> [[ The URN q-component has the same syntax as the URI query
> component, but is introduced by "?=", not "?" alone. For URNs that
> may be resolved to a URL, the semantics of the q-component are
> identical to those for the query component of that URL. Thus URN
> resolvers returning a URL for a URN with a q-component do this by
> copying the q-component from the URN to the query component of the
> URL. It the URN does not resolve to a URL, the interpretation of the
> q-component is undefined by this specification. An example of the
> copying operation appears below. ]]
>
> This leaves the question open, what will happen if a URN with a
> q-component resolves to a URL that already has a query component.

Hmm. You are correct that we have not considered this case.

> My
> take is that that case is outside the scope of 2141bis, but I think
> we should be explicit about that and suggest that we add some text
> along the following lines:
>
> [[ It is possible that a URN with a q-component resolve to a URL that
> already has a query component. In that case, the final URL will end
> up having a query component consisting of the URL's original query
> component and the q-component from the URN. If the new query
> component makes sense is outside the scope of this specification. ]]

One messy aspect of this approach is the potential for overlap of fields 
in the query component.

To use an artificial example, what if the URL query component includes a 
credit card field named "cc" and then the URN resolver attempts to 
append "CCResolve:cc=uk"? Now we have two fields named "cc" in the URL 
query component. Untangling this mess could be a matter for the URL 
resolver, or we could stipulate that the URN resolver needs to return an 
error. Alternatively, we could state some other rule (e.g., remove the 
URL query component) or leave this all up to the implementation.

I'll think about this further.

Peter

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 22 Dec 2016 22:32:57 +0000

It occurs to me that this might be related to a previously unsolved
problem: consider the case where an HTTP redirect specifies a fragment,
but the URI that launched the request had a fragment as well.  Answer:
confusion/competing standards/recommendations/practices, AFAI can tell.
See e.g.

  http://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects

Or, consider that various serverside tools provide for a range of
possible actions wrt the original query string and the query string in the
redirect target, with various default behaviours if one or the other or
both are/are not present [1], [2].

Net result: we don't want to get into specifying that, IMO: different
resolvers will behave differently, just as different webserver
configurations today behave differently with fragments and query
strings.

ht

[1] http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteflags
[2] https://www.viget.com/articles/merging-query-strings-when-redirecting-in-rails
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 23 Dec 2016 08:25:11 +0000

Hello, 

Comments inline below. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: 22. joulukuuta 2016 22:43
> To: Svensson, Lars <[email-masked]>; [email-masked]
> Subject: Re: [urn] q-component: What happens if the URL resolved to
> already has a query component?
> 

> > ... what will happen if a URN with a
> > take is that that case is outside the scope of 2141bis, but I think we
> > should be explicit about that and suggest that we add some text along
> > the following lines:
> >
> > already has a query component. In that case, the final URL will end up
> > having a query component consisting of the URL's original query
> component
> > makes sense is outside the scope of this specification. ]]

We might also say that if a URN with a q-component resolves to a URL that already has a query component, the q-component shall replace the original query component in the resolution process. Then the resulting query component should make sense, and produce the result the client wants. There is no guarantee that the combined query would do that.   

If a resolver has a default resolution service established with a query component, clients should still be able to require other services which may be supplied by other q-components. Overwriting the default query component - if there is one - will facilitate this functionality. Keeping both existing query component and incoming q-component in the final URL is, in my opinion, a bad choice because it is likely that the resulting combo-query does not make sense either to the resource or to the system supplying the resource. Resolvers are not required to be able to parse q-components, and therefore we cannot trust them to make sanity checks. 

Since URN resolvers have not been dealing with q-components yet, there are no resolvers out there already behaving in some other way. 
 
> One messy aspect of this approach is the potential for overlap of fields in the
> query component.
> 
> credit card field named "cc" and then the URN resolver attempts to append
> "CCResolve:cc=uk"? Now we have two fields named "cc" in the URL query
> component. Untangling this mess could be a matter for the URL resolver, or
> we could stipulate that the URN resolver needs to return an error.
> Alternatively, we could state some other rule (e.g., remove the URL query
> component) or leave this all up to the implementation.

I would not want to leave this issue open because then we either get questions of how to implement this feature correctly, or non-interoperable resolvers. 

Juha
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Dec 2016 09:31:12 +0100

On 2016-12-22 23:32, Henry S. Thompson wrote:
> ...

There's one standard, and I believe what it says is actually implemented 
by most UAs...

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Dec 2016 14:52:57 -0500

--On Friday, December 23, 2016 9:31 AM +0100 Julian Reschke
<[email-masked]> wrote:

>> It occurs to me that this might be related to a previously
>> unsolved problem: consider the case where an HTTP redirect
>> specifies a fragment, but the URI that launched the request
>> had a fragment as well.  Answer: confusion/competing
>> standards/recommendations/practices, AFAI can tell. See e.g.
>> 
>>   http://stackoverflow.com/questions/2286402/url-fragment-and
>>   -302-redirects ...
> 
> There's one standard, and I believe what it says is actually
> implemented by most UAs...

Julian, assuming the "one standard" part correct, do you believe
that 2141bis needs a reference to it and, if so, what reference?
Or, if you believe that this is not an issue, despite Henry's
and Juha's concerns, could you explain a bit more about why?

thanks and regards,
    john

---

From: Julian Reschke <[email-masked]>
Date: Tue, 27 Dec 2016 23:34:11 +0100

> that 2141bis needs a reference to it and, if so, what reference?

No, I don't think that the URN spec needs to talk about this, as it is 
about HTTP redirects.

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 27 Dec 2016 22:54:58 +0000

> No, I don't think that the URN spec needs to talk about this, as it is

There may or may not be a spec about the handling of query strings in
various HTTP redirect cases.  2141bis doesn't _need_ to talk about that,
but my point was that the case of q-components handling during URN
resolution that Juha raised was in some ways parallel to the HTTP case,
and the uncertain nature (IMO) of the situation wrt the HTTP case should
be raise a 'caution' flag for 2141bis.

My net: explicitly duck the issue: "This specification does not specify
a required behaviour in the case of URN resolution to a locator when the
original URN has a q-component and the locator has a query string.
Different circumstance may require different approaches.  Resolvers
SHOULD document their strategy in such cases."

ht

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Dec 2016 00:17:13 +0100

> be raise a 'caution' flag for 2141bis.

How exactly is it "uncertain"? Do you believe there's something in RFC 
7231 that needs to be fixed?

Best regards, Julian

---

From: [email-masked] (Henry S. Thompson)
Date: Tue, 27 Dec 2016 23:39:54 +0000

[Subject changed because this is no longer about 2141bis]

Julian Reschke <[email-masked]> writes:

> How exactly is [the HTTP redirection case when both original and
> redirect target have query strings] "uncertain"? Do you believe
> there's something in RFC 7231 that needs to be fixed?

I don't see anything in 7231 at all about query string 'conflict' or
merging or ...  Where should I be looking?

ht

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Dec 2016 19:20:33 -0500

wfm.  Text tentatively incorporated.
   thanks,
     john

--On Tuesday, December 27, 2016 10:54 PM +0000 "Henry S.
Thompson" <[email-masked]> wrote:

>>> Julian, assuming the "one standard" part correct, do you
>>> believe that 2141bis needs a reference to it and, if so,
>>> what reference?
>> 
>> No, I don't think that the URN spec needs to talk about this,
>> as it is about HTTP redirects.
> 
> There may or may not be a spec about the handling of query
> strings in various HTTP redirect cases.  2141bis doesn't
> _need_ to talk about that, but my point was that the case of
> q-components handling during URN resolution that Juha raised
> was in some ways parallel to the HTTP case, and the uncertain
> nature (IMO) of the situation wrt the HTTP case should be
> raise a 'caution' flag for 2141bis.
> 
> My net: explicitly duck the issue: "This specification does
> not specify a required behaviour in the case of URN resolution
> to a locator when the original URN has a q-component and the
> locator has a query string. Different circumstance may require
> different approaches.  Resolvers SHOULD document their
> strategy in such cases."
> 
> ht

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Dec 2016 09:57:39 +0100

> merging or ...  Where should I be looking?

Ah, I misread. Thought this was solely about fragment identifiers.

It doesn't say anything about merging query strings, because they 
aren't. It's not part of the reference resolution defined in RFC 3986.

Are you aware of any user agents doing something like merging on redirects?

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Dec 2016 18:27:37 -0700

> wfm.  Text tentatively incorporated.

WFM too.

Peter