Hacker News Reader

Comment by stonogo | Hacker News Reader

This doesn't explain why query parameters in a .well-known URI is a bad idea, it just explains that you don't like them. That's fine, and I agree with you, but I'm asking for the actual technical reason people are claiming query parameters in a .well-known URI is a bad idea.

View on HN

I’d say it’s a bad idea when you can implement most .well-known features by just touching or copying static files into the right directory, and then suddenly a .well-known feature comes along that expects something smarter than a static file server, and now you’re doing complex routing just to patch that request over to a process that can actually service it.

This is the same argument people made against CGI, and web apps in general, and that argument turned out to be on the wrong side of history. What makes .well-known URIs different?

It's not the same argument at all. When there's functionality that needs to be dynamic that is fine. When there's functionality that could have been easily accommodated without it, it forces sites that otherwise could remain entirely static to be served up with a dynamic setup or use a redirect to somewhere to run a dynamic script just for that. If it was for a good reason, such as lack of ability to provide the functionality in a static way anyway, it'd have been fine, but providing webfinger with static files would've been easy with just a tiny bit more care.

E.g. here's a suggested change to webfinger that wouldn't made this purely optional:

* Change the basic URL format to /.well-known/webfinger/<acct>

* Still allow the "rel" parameter, but allow the server to ignore it and return the full set of resources.

Now all you lose is the ability to do filtering with "rel=", and the "failure mode" is simply that you get the whole static file returned if it's not supported.

The actual technical reason is that it prevents us from implementing it with static files.

I'm not sure that's true. You can map these URIs, params and all, to static files behind the httpd. Nothing is forcing anyone into running a dynamic application. Even if you don't want to map characters, all the param characters are valid in unix filenames.

Anyway here's someone doing webfinger with a static file, in a way that works for serving for multiple users: https://gist.github.com/aaronpk/5846789

That’s really cool! Thanks for sharing, but doesn’t a rewrite rule still require an active web server component and not static file listing?

I’m not sure if you could implement something similar with s3

> You can map these URIs, params and all, to static files behind the httpd. Nothing is forcing anyone into running a dynamic application.

Sorry, but this is a form of equivocation[1] at best. More honestly, it's a simple contradiction; at the point where you're "map[ping] these URIs, params and all, to static files", you are being forced into running such an application.

Although it's not a rigorous, well-defined term, it's widely understood what a "static" site is. It's the sort of thing you get with e.g. Neocities or GitHub Pages or one of its clones—where you cannot rely on being able to mess with the server configuration (past the point of specifying the hostname your site should respond to, if even that). Any more involved configuration moves it out of this realm and towards the dynamic systems that many people are not running and not interested in running—for various reasons, including pricing, maintenance, and sheer complexity/brittleness. A static site is a place where you dump a directory of files and the host doesn't do much beyond serving that file with the appropriate media type when someone requests it, which is pretty much the only thing that people can trust to work reliably if and when they move all their crud to another host and/or server configuration someday.

1. https://en.wiktionary.org/wiki/equivocation

The problem with this is that the webfinger spec allows additional parameters (e.g. "rel"), so if you do this you violate the spec.

(EDIT: Actually given it does a full regex match it might work; though it'll return supersets of the intended results if rel= constraints are preset, and possibly break if the rel= argument is put after the "resource=" in the URL so would need refinement; of course it depends on using a server which allows arbitrary regex based rewrites, which rules out a lot of object storage etc.)

It may happen to work for some clients some of the time, until it suddenly doesn't.

Reply on news.ycombinator.com