Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 20:04:37 -0300

I am guessing this is wrong or the text needs to be clarified.

HTTP/1.1 307 Temporary Redirect
     Location: http://wf.example.net/example.com/webfinger?
                       resource=acct%3Aalice%40example.com HTTP/1.1

   The client MUST follow the redirection, re-issuing the request to the
   URL provided in the Location header.

If the primary method of delegation is redirect, one expects the client to take the redirect URI and append the appropriate query parameters to it and reissue the request.

The réponse  the input query parameters parameters, indicating the redirect URI is opaque to the client.  
On the face of it that would be OK but if a sever can do a dynamic redirect based on query parameters can probably also run a WF server.

I thought the redirect was supposed to be to the new base URL.

If the server is repressible for completely formatting the redirect URI including query parameters that needs to be made clearer to the server developers.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 20:32:19 -0500

John,

Servers always return URL parameters as a part of the 3xx.  Try this:

$ curl -v http://www.twitter.com/?test=123

It should return a 3xx referring you to twitter.com and it will include the
URI parameter in the Location header.  The client would not append yet
another parameter onto it.  And we would not want it to.  The server might
redirect the client to an entirely different user account or other URI as
the new resource.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of John Bradley
Sent: Monday, December 03, 2012 6:05 PM
To: [email-masked] Discuss
Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong

 

If the primary method of delegation is redirect, one expects the client to
take the redirect URI and append the appropriate query parameters to it and
reissue the request.

The réponse  the input query parameters parameters, indicating the redirect
URI is opaque to the client.  

On the face of it that would be OK but if a sever can do a dynamic redirect
based on query parameters can probably also run a WF server.

If the server is repressible for completely formatting the redirect URI
including query parameters that needs to be made clearer to the server
developers.

John B.

---

From: Mike Jones <[email-masked]>
Date: Tue, 4 Dec 2012 01:53:33 +0000

I believe Paul is correct here

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Monday, December 03, 2012 5:32 PM
To: 'John Bradley'; [email-masked]
Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong

John,

It should return a 3xx referring you to twitter.com and it will include the URI parameter in the Location header.  The client would not append yet another parameter onto it.  And we would not want it to.  The server might redirect the client to an entirely different user account or other URI as the new resource.

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, December 03, 2012 6:05 PM
To: [email-masked]<mailto:[email-masked]> Discuss
Subject: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong

                       resource=acct%3Aalice%40example.com<http://40example.com> HTTP/1.1

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2012 23:38:01 -0300

I didn't say the redirect can't contain a query parameter.   

I was questioning if the server doing the redirect is always expected to rewrite the parameters in the request URI into the URI in the location header.

If that is the case the spec is not clear on that.  The example shows it but there is no normative text saying the redirect is a fully qualified URI to the JRD and not to a new WF endpoint.

I agree that is probably the correct thing to do as long as people are clear on what we are asking the server to do and not going to push back on the complexity to do that sort of redirect.

It also seems likely that any server capable of that redirect writing is probably also capable of being a WF server itself.

John B.

On 2012-12-03, at 10:32 PM, "Paul E. Jones" <[email-masked]> wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 3 Dec 2012 21:47:22 -0500

John,

No, they would not be required to do that.  For example, if you query about
me, my server might return a 301 pointing to a specific file somewhere that
contains the JRD.  The query parameters would not be required.

Nothing magical here that needs much explanation, IMO.  This is how HTTP
redirection works.  We’re adding or removing nothing from it.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Monday, December 03, 2012 9:38 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] Web Finger Draft 07 Sec 8 Example response wrong

I was questioning if the server doing the redirect is always expected to
rewrite the parameters in the request URI into the URI in the location
header.

If that is the case the spec is not clear on that.  The example shows it but
there is no normative text saying the redirect is a fully qualified URI to
the JRD and not to a new WF endpoint.

I agree that is probably the correct thing to do as long as people are clear
on what we are asking the server to do and not going to push back on the
complexity to do that sort of redirect.

It also seems likely that any server capable of that redirect writing is
probably also capable of being a WF server itself.

John B.

John,

$ curl -v  <http://www.twitter.com/?test=123>
http://www.twitter.com/?test=123

It should return a 3xx referring you to  <http://twitter.com> twitter.com
and it will include the URI parameter in the Location header.  The client
would not append yet another parameter onto it.  And we would not want it
to.  The server might redirect the client to an entirely different user
account or other URI as the new resource.

Paul

HTTP/1.1 307 Temporary Redirect
     Location:  <http://wf.example.net/example.com/webfinger?>
http://wf.example.net/example.com/webfinger?
                       resource=acct%3Aalice% <http://40example.com>
40example.com HTTP/1.1

 

John B.