If you want to do this yourself, caddy http server [0] works really well and is incredibly easy to use / setup. They even have an example on their home page that shows this for /api and /blog
It's trickier than it seems, though, because you need to get the right combination of Host/X-Forwarded-Host right for a given hosting service. And you frequently need to rewrite HTML to fix links. Not rocket surgery, but usually I'd rather put my hours into dev and not tweaking a proxy.
This is exactly what I use to run a bunch of different personal services in subfolders on the same hostname. Sadly, though some things don't support running in subfolders.
Pretty specific use-case, but if you use Rancher for Docker orchestration, the built-in load-balancer service that you can deploy makes this pretty easy.
What about the protections from XSS which Content Security Policies[0] can provide? It would be unfortunate when a bug in your blog engine can cause a hack of your store.
For some reason I believed that CSP rules can be hostnames but not paths. At least in Mozialla's documentation above there is not a single example of a rule with a full path. I can't check it by myself right now to find out the truth as I'm far away from my development PC.
Notably, there is no query portion or fragment portion; browsers are expected to ignore those. Path matching works like a prefix if it ends in a slash. If it doesn't, only exactly that path matches.
In CSP3, the secure protocol/scheme (https, wss) always matches, even if you explicitly specify http://. In CSP2, the implicit scheme matches either; an explicit scheme only matches that scheme. This is typically not useful behavior because you probably have HSTS anyway, so people just use hostnames and only rarely specify the protocol. Most values in practice seem to just be hostnames in general; paths too are rare.
CSP doesn't help unless you can apply a strict policy to every page of your site. If a single page has an XSS, that gives js execution to the attacking code, which can then steal cookies, forge requests, exfiltrate localstorage, etc.
With multiple domains, you at least can limit the blast radius of an XSS; on the same domain, most protections can be circumvented. E.g. there's no cors protection, so if different apps use different implementations of csrf, just fetch a the other app's page over XHR and parse out it's csrf token; it's probably their or in a cookie which you should be able to read.
I still don't know what this is for, all the fluff (inserted to keep the reader's attention when explaining stuff that might be boring) gets in the way.
They seem to work in similar ways, but Cloudflare focuses on speed and security, this just seems to focus on SEO. The security risk is in theory the same, but I'd argue that the risk from Cloudflare is lower as they're a well established service used by major companies.
Okay, so the claim is subdomains = bad, subfolders = good.
Is that true? I'm seeing vague claims ("Subdomains accumulate positive signals differently than root domains") without anything of substance to back up their veracity or relevance.
> Many people have tested this and written about their results:
But I can also find articles saying that subdomains are good for SEO, and Google itself says that subdomains are treated the same as subdirectories.[1]
Even these articles will mention that the benefits to SEO are secondary to good, relevant content that is well structured and semantic. There are downsides as well. Your ability to run paid search is limited by your domain. You can't bid for multiple positions on the same keyword with a single property. In practice, our businesses have had a much better return from the SEM benefits than the minor SEO boost.
These stylized landing pages benefit from branding, and usually aren't a tremendous amount of searchable content (I doubt anyone will ever find onehostname.com with a search engine).
I'm not too worried about Google's algorithm changes. SEO is one "free" benefit of putting everything on a single hostname, but there are lots of reasons it's desirable. You get better speed (especially with tls and http2), more control, even vanity. What we're really helping people do is manage their stuff that's scattered across 15 different services and make sure they're all delivered to end users well.
I spent 30 seconds looking at this, and have no idea what they are selling. The first "usable" content was something about taking down blue towers. If you have to sell me on the basis of a stretched LOTR reference, I am going to assume your actual value proposition doesn´t really hold its´own.
I love the landing page story. I also strive for single hostnames, but preferably out of one's own server through a proxy in front instead of folders. Relative URLs in subfolders just don't seem to work well on dynamic websites.
One problem I haven't figured out with this app-level routing, though, is how to have a reliable status endpoint. The distance the pinging server needs from the app's running process is at odds with this routing strategy.
This could be an object lesson in how not to build a landing page. What is this? What is it for? I see a cartoon...but what the hell does any of it mean? Why am I signing up? What am I signing up for?
> Want all your applications on One Hostname?
Uh...no? Should I? I have no idea!
Oh look. Tiny, low contrast text at the very bottom of the page linking to an article that loses my interest before it gets to the point.
This could have been 24 point bold arial black on white: "We made a service called Fly to help you convert subdomains into load-balanced subdirectories to strengthen your brand and improve[0] your SEO. yada yada yada..."
Aw, come on. Not everything posted to Hacker News needs to explain itself in a commonplace way. There's a place for the playfully obscure too. Reacting with rage seems like a parody of the angry spoilsport.
In the spectrum of HN consciousness there's a large chunk of rule-bound literalism. Part of the work of this community is for that to breathe a little and not need to impose itself everywhere. Then everything works better and life becomes more sparkly.
I found the page interesting and pretty, but had absolutely no clue what service it was offering. It's not so much that it needs to explain itself in a commonplace way, as ... explain itself at all!
> There's an honored place for the playfully obscure too.
I get enough of this from work, thanks. There's a fine line between decoding twee whimsy and billable hours that most of these submissions stomp past obliviously.
The first rule of writing is: respect your reader's time (or else they won't read you). I'm all for not taking things to seriously, but if I have to spend 5 minutes to work out if this is an entertaining flight of fancy that I might just learn something from, or an untargeted waste of marketing budget, then I'm going to Have Opinions that I want to Share Online.
The underlying expectation here seems to be that HN readers shouldn't have to work a little. But HN thrives when readers do occasionally have to work a little. So we welcome that. Sorry!
> The underlying expectation here seems to be that HN readers shouldn't have to work a little
That's not my point at all: I work in software, so I love to stare at some cryptic message and mutter and make notes. But when I uncover the answer is "Be sure to drink your Ovaltine", then I'll feel ripped off.
I keep seeing product announcements using this technique of dressing it up in twisty little language, as if they're afraid that what they're saying isn't interesting enough to stand on its own. They slap on the appearance of entertainment, without considering how well it fits with their message (prioritising form over function).
why's (poignant) Guide to Ruby is a fantastic example of how to do it right: the whimsy doesn't detract from the message, but helps frame it and gives the right context for the reader to build the mental model of programming that _why intended to convey.
> if I have to spend 5 minutes to work out if this is […] an untargeted waste of marketing budget, then I'm going to [write a comment about how I wish people would stop doing it]*
HI there! Duly noted! Annie here (I drew the comic). This is a little "gift" that people will come across when they start their journey toward using onehostname. Sorry for the confusion since it's out of context. And your feedback is really helpful!
I think you're probably not in the target audience for a comic like this. It's meant to be light and fun, and appeals to people who already want to put all their stuff on one hostname. All the normal "what do you do? why? how?" questions don't really apply here, that's more what our homepage is for.
Totally disagree. The landing page is nice, is pretty, it invites you to read and has two very useful links.
If it was a black on white page I would have read it, acknowledge it and close, perhaps add it to Pinboard for later use and never look at it again. The way it is now I've clicked the links and read the whole article, almost.
I, and I suppose a lot of people, give between 3-5 seconds to tell me what it does. If I am not able to find a reference to anything within this time - I will close the tab.
I have scrolled whole website looking for one headline or enlarged text with one sentence explanation of what this is.
Once I failed I turned in to HN comments.
UX on this website is awful, but it has a possibility to be an amazing one. Just a few small changes and people will link to this page as an example of UI. But for now is pretty bad.
Hehehe. This was a bit mean, but there's truth. I've adjusted the page based on the feedback here. Now it's "here's the article for more information" instead of "sign up for this mystery box". :)
