Subject: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD

From: "Manger, James H" <[email-masked]>
Date: Tue, 10 Jul 2012 17:28:24 +1000

Various people have said that many (big?) sites will not want to serve per-user discovery details from their top-domain. For example, they will serve it from https://id.example.com/, not https://example.com/.

Redirecting all discovery request from example.com to id.example.com works, but it does add a round trip. If clients can determine that the redirection will apply to all future discovery requests, not just the specific one they are currently making, then the extra round trip is a once-off that can be ignored.

SWD solves this with its content-layer SWD_service_redirect.

WebFinger-without-resource-parameter solves this by providing a template for per-user details that can use another domain, eg https://id.example.com/user?u={uri}; or by redirecting the (non-user-specific) initial request.

WebFinger-with-a-resource-parameter and draft-snell-web-index don't solve this issue.

Ideally, we should solve this at the HTTP layer. An HTTP 3xx response should be able to indicate that the same response applies to all URIs with a given prefix. How about:

  HTTP/1.1 307 Moved
  Location: https://id.example.com/user?u=acct:[email-masked]
  Redirect: /.well-known/finger https://id.example.com/user

The "Redirect" header includes a path-prefix and destination URI. The same redirect applies to any request whose path starts with path-prefix. The part of the request after the path-prefix is appended to the destination URI to get the new location.
It is potentially dangerous (a response from any resource on a site can redirect requests to all other resources on the site), but that might be solvable.

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jul 2012 10:00:20 +0200

On 2012-07-10 09:28, Manger, James H wrote:
> ...

Sounds like the Redirect-Ref response header defined in 
<http://greenbytes.de/tech/webdav/rfc4437.html#rfc.section.12.1> (which 
gets away with a single URI or URI-reference).

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 10 Jul 2012 05:52:54 -0700

This could certainly work but it does make me nervous precisely
because of the potential danger you point out. For this to work in
practice, we would need a mechanism for the user-agent to verify the
Redirect header. Should definitely be solvable tho... and definitely
something that would be useful outside resource discovery.

On Tue, Jul 10, 2012 at 12:28 AM, Manger, James H
<[email-masked]> wrote:
[snip]

---

From: James M Snell <[email-masked]>
Date: Tue, 10 Jul 2012 06:42:22 -0700

Then again... thinking about it further... why wouldn't a reverse
proxy work here? It would certainly be safer... (of course... I may
need to put the laptop down and go get more coffee too)

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 10 Jul 2012 23:19:57 -0400

James,

If it is true that large sites will always host LRDD content at a separate
location, then perhaps if the first query to such a site results in a 3xx
redirection then the client interested in optimizing queries should issue a
subsequent query without the "resource" parameter to discover the location
of the LRDD resource.

I like the thinking proposed of introducing a new HTTP header, but that
could be of general interest outside of WebFinger.  Further, one might want
to use URI templates (RFC 6570) with such a new HTTP header.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Manger, James H
> Sent: Tuesday, July 10, 2012 3:28 AM
> To: James M Snell; IETF Apps Discuss
> Subject: [apps-discuss] redirects in draft-snell-web-index/WebFinger/SWD
> 
> Various people have said that many (big?) sites will not want to serve
> per-user discovery details from their top-domain. For example, they will
> serve it from https://id.example.com/, not https://example.com/.
> 
> Redirecting all discovery request from example.com to id.example.com
> works, but it does add a round trip. If clients can determine that the
> redirection will apply to all future discovery requests, not just the
> specific one they are currently making, then the extra round trip is a
> once-off that can be ignored.
> 
> WebFinger-without-resource-parameter solves this by providing a template
> for per-user details that can use another domain, eg
> https://id.example.com/user?u={uri}; or by redirecting the (non-user-
> specific) initial request.
> 
> Ideally, we should solve this at the HTTP layer. An HTTP 3xx response
> should be able to indicate that the same response applies to all URIs with
> a given prefix. How about:
> 
>   HTTP/1.1 307 Moved
> The "Redirect" header includes a path-prefix and destination URI. The same
> redirect applies to any request whose path starts with path-prefix. The
> part of the request after the path-prefix is appended to the destination
> URI to get the new location.
> It is potentially dangerous (a response from any resource on a site can
> redirect requests to all other resources on the site), but that might be
> solvable.
> 
> --
> James Manger
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss