Is there already a way to support URL redirects in dat sites? This is pretty essential if you change the permalink structure of the site, and want to redirect old links to the new locations. I couldn't find find a spec for this in the Wiki yet, so I guess nothing's decided yet.
The way I'd do it is to look put a 302.txt file at the old link's location with the content:
/absolute/path/to/new/location
or:
../relative/path/to/new/location
When faced with an unresolved request, Beaker would first look for an index.html at that location, then for 302.txt, and then either a directory listing or 404. If the need arises to support other HTTP status codes, they could be implemented in the same way.
Interesting question. A 302.txt could work but you'd need to create a directory for each redirect.
I'm inclined to think a dat.json entry should be added. Perhaps something like:
{
"redirects": {
"/old-path": "/new-path", // path within the same site
"/other/old.html": "dat://newsite.com/new.html" // new origin
}
}
Would we need to specify status codes or could we just chose one of the 3xx?
The dat.json solution could work as well yes. It's probably more convenient to use in most cases, and maybe also a bit better performance-wise.
To keep the json format straightforward, I think the best thing would be to choose just one of the 3xx codes. I haven't really thought of a clear use case for any of the other status codes yet, so I don't see a problem there, unless someone else has a case for other statutes.
I was having a look at how some other static site hosts solve this problem, and the approach taken by the people at @surge-sh looks interesting too: https://surge.sh/help/adding-redirects. It has all the advantages of the dat.json approach, while also retaining a separation of concerns between metadata and routing logic.
Not bad
I wrote a small module to parse the Surge-style routesfiles. If you're on board with it, I could draw up some PRs to use it both here and in dathttpd.
Hey brecht, awesome. I'm going to think about this a little bit, because whatever we choose effectively becomes part of the Dat Web standard that we're proposing.
Sounds reasonable, I'll keep an eye on this thread to see what's decided.
Something I should have thought of before: I decided to check how Github Pages handles this issue, as it's another popular static site hosting service. (Possibly the most popular...) Turns out they use a Jekyll plugin which just creates an empty HTML file at the old location, with in the head the tag:
<meta http-equiv="refresh" content="0; url=http://example.com/new-location">
While it looks a bit fishy, apparently search engines deal with this just fine.
So what do you think? Would this suffice as a dat standard? For me personally this solves it, so if you think it's good enough for general use you can close this issue.
If it's a web standard, then you don't even need dat to explicitly support it. Though it might be useful for beaker to generate these pages for you.
@brechtpm I think for now that's probably the best solution, and we can leave this open for further discussion
Most helpful comment
Something I should have thought of before: I decided to check how Github Pages handles this issue, as it's another popular static site hosting service. (Possibly the most popular...) Turns out they use a Jekyll plugin which just creates an empty HTML file at the old location, with in the head the tag:
While it looks a bit fishy, apparently search engines deal with this just fine.
So what do you think? Would this suffice as a
datstandard? For me personally this solves it, so if you think it's good enough for general use you can close this issue.