Re: [apps-discuss] Looking at Webfinger

["Paul E. Jones" <[e-mail]>]

George,

 

I believe it might be useful to introduce those who break your WebFinger
server to Louisville Slugger. :)

 

Your pain is understood, but I do not see a way to avoid it.  We could
introduce something in DNS, but that would also present challenges.  No
matter where we "root" the discovery process, there is a potential somebody
could break it.  It could be rooted somewhere other than the root of the
domain (e.g., webfinger.example.com), but we either need to decide in
advance of such a location or introduce a way to discovery the discovery
resources.

 

Do you have a suggestion that would make this less likely to be broken?

 

Paul

 

From: [e-mail] [mailto:[e-mail]]
On Behalf Of George Fletcher
Sent: Tuesday, August 28, 2012 11:09 AM
To: Mark Nottingham
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Looking at Webfinger

 

Way "late to the party" but I can speak from experience that deployment can
be a real issue in some environments. It's all really straight forward in a
small company or an environment where the identity team "owns" the root
domain (e.g. example.com). However, if an entire other group in a large
organization "owns" the root domain (home page for the site) and the
identity team then needs to get them to make changes, the deployment
solution gets brittle pretty quick. I've had our webfinger support broken at
least twice because the "other" team didn't know that certain configs were
required:)

Also, installing the "dynamic pluming" can be more problematic is these
cases. It is possible to get apache rewrite rules or netscaler magic in
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:

Mark -- Of course I was speaking about practical realities of typical web
server administration and deployment.  In practical terms, adding a new
mod_rewrite rule or moral equivalent is going to be easier than adding a new
PHP script that connects to a database.  The latter is just always going to
be a much higher bar. 

 

And, something that returns per-user data is generally going to need a
dynamic service of some kind, unless your site has just a handful of users
and you don't mind going through a publishing exercise each time you add or
change a user...

 

None of this has anything to do with the interface, just deployment
realities.  And in reality all of this is going to need a dynamic service
somewhere for each non-trivial site, this is all just a question of how to
hook it up.




--
John Panzer / Google
[e-mail] / abstractioneer.org <http://www.abstractioneer.org/>  /
@jpanzer

 

 

On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <[e-mail]> wrote:

On 05/07/2012, at 8:16 AM, John Panzer wrote:

> Just as a historical note.  The envisioned usage of host-meta was
originally to avoid a specification which mandated a particular dynamic URL
API at a particular /.well-known endpoint (because it may not be feasible to
do that across all organizations and deployments).  The host-meta document
itself would be highly cacheable and so wouldn't incur an additional network
trip in the common case.
>
> Having a 3xx redirect is a reasonable alternative that allows a similar
escape hatch via something like mod_rewrite, albeit at the cost of needing
an additional network trip each time.  Since a deployment can always avoid
the 3xx redirect with additional dynamic plumbing behind the well-known
endpoint, I don't think that's a horrible thing.
>
> An application-level redirect would be almost equivalent to an HTTP
redirect, but then there are two ways to do the same thing.  If _only_ an
application-level redirect is allowed, then you have to have at least a
minimal dynamic service at the well-known endpoint (no more mod_rewrite).
But the whole reason for this is to avoid the requirement for a dynamic
service behind well-known...

"dynamic" and "static" are properties of the implementation, not the
interface. HTTP doesn't require that any particular URL be "dynamic";
anything can, with the right metadata, be cached (and indeed, I've cached
many, many things with the wrong metadata, because of silly site operators
and their ideas about "dynamic").

Now, if people want to target a particular implementation that makes it
easier to serve a particular style of URL without writing code, fine, but
let's not confuse things.

E.g., a URL like

http://example.com/.well-known/user/bob

is easy to serve in pretty much any way you like with Apache.

I'm also going to push back on the "it may not be feasible to do that across
all organizations and deployments" motivation. This is a race to the bottom.
The trick is to make it accessible enough to get sufficient traction to pull
everyone along, without pandering to *everyone*'s requirements.

Regards,


--
Mark Nottingham   http://www.mnot.net/




 






_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss