search

udleinati / redirect.center

Redirect domains using DNS only
http://redirect.center
MIT License
261 stars 49 forks source link

Allow redirecting to HTML anchors #22

Closed GSI closed 2 years ago

GSI commented 6 years ago

foo.bar.example.org => www.example.org/#foo.bar

Can this be achieved?

meowingcat commented 5 years ago

easy redirect to a html page thats redirect on the html anchor url. foo.bar.example.org - > your-site.ext/redirect_anchor.html redirect_anchor.html > <meta http-equiv="refresh" content="0;URL='www.example.org/#foo.bar'" />

meowingcat commented 5 years ago

else try with yoursite.ext.opts-slash.[site+anchor].redirect.center

GSI commented 5 years ago

Are the brackets explicit? Can you give an example? My DNS provider appears to reject []+#.

tmackay-cenet commented 4 years ago

I am also encountering some issues migrating existing redirects containing special characters '+#%:' etc. URLEncoding with % looked promising, but some DNS clients reject the record. I'm also a little concerned about CNAME record length. It would be fairly trivial to add some more "escape codes" like .opts-dot. .opts-pct. .opts-frg. etc. which I might try first. Would it be of value to offer an alternate scheme? I was thinking of deflate+base64 encoding the entire redirect URL. This would cover several use cases including alternate protocols, ports, case sensitivity etc. and also only require one level of subdomains and allow for backward compatibility.

tmackay-cenet commented 4 years ago

I've been playing around with a few options, first adding support for more common special characters used in paths/queries (eg. https://lmgtfy.com/?q=redirect.center) but quickly ran out of room in a 253 character CNAME so I also added a shorthand representation. Dots in the path were also problematic so I escaped them too. More obscure characters may be URL encoded with '%'.

'/' => .opts-slash. (._s.)
'?' or & => .opts-query. (._q.)
'=' => .opts-eq. (._e.)
'%' => .opts-per. (._pc.)
'+' => .opts-plus. (._p.)
':' => .opts-colon. (._c.)
'#' => .opts-hash. (._h.)
'.' => .opts-dot. (._d.)

Now I am able to encode modest URLs with query parameters without going over the limit: eg. https://www.google.com/a/mycustomdomain.org.au/ServiceLogin?service=CPanel&continue=https://admin.google.com becomes www.google.com._s.a._s.somecustomdomain._d.org._s.ServiceLogin._q.service._e.CPanel._q.continue._e.https._c._s._s.admin._d.google._d.com._https.redirect.center.

Any thoughts?

Edit: Reading this now, all those subdomains making up the path take up a lot of space. Alternatively we could use URL encoding but using underscore instead of percent (then escaping real underscores). This would save a bit more space but now we're talking about breaking backwards compatibility. The hostname code could be tweaked to not pick up the dots in the path alleviating the need to escape all of them (consecutive dots are still an issue).

udleinati commented 2 years ago

Is this still an issue? the issue can be solved using base32 encode option.