-
Notifications
You must be signed in to change notification settings - Fork 337
Always upload .well-known
dotfiles
#980
Comments
Figured out that
So they seem to be there, but I can't get them via Curl as I can /.well-known/keybase.txt. What are the hash-looking things after the file's base and before the extension? Wondering if something is confused by the lack of extension on my /.well-known/matrix/* files. This is kind of unintuitive. Every other platform I've worked with happily assumes that anything in public/ is meant for serving. I may still have some header massaging to do to ensure that, say, /.well-known/matrix/server gets the correct content-type, but it shouldn't be this hard to just ship my directory content and count on it arriving intact. Thanks. |
Thanks for the feedback. We don't upload hidden files by default because if there is any sensitive info, it will be served globally on our network.
Hashes of the content contained in the file to ensure unique content is cached on Cloudflare properly. It's pretty fascinating how we implemented this, read more here: https://blog.cloudflare.com/extending-the-workers-platform/
A mime library is used to determine the content type to serve from the extension. Would you mind sharing the actual results of the curl with the |
Thanks. It's a 404. The URLs:
https://lightsoutgames.nolan.workers.dev/.well-known/keybase.txt works
https://lightsoutgames.nolan.workers.dev/.well-known/matrix/server doesn't
Both files appear in my public/ directory.
My wrangler.toml site config:
```
[site]
bucket = "./public"
include = [
"*",
".well-known/matrix/*",
]
```
Not sure if I need the additional .well-known path, or if it needs to be
relative to the bucket. I think I tried both.
Thanks.
|
A custom 404 is caching:
Did you adjust the cache settings on |
No changes to index.js. I do eventually need to tweak the content-types
of files in .well-known, but I thought I'd get them serving first.
I ran `rangler kv:namespace delete` on both existing namespace IDs
(preview and deployed site) and verified that `wrangler kv:namespace
list` is empty. Same result.
Thanks for the help so far.
|
Sorry for the back and forth, we actually don't serve files without extensions. After speaking with the team, we agree the kv asset handler should though, so we are moving this issue to that repo. In the meantime, you can work around this for your project by passing in a customer modifier to Code would look something like
See more docs on this at https://github.com/cloudflare/kv-asset-handler#maprequesttoasset |
Thanks. Where can I find the newly-opened issue? Poked around
https://github.com/cloudflare/kv-asset-handler/issues but nothing looked
immediately promising.
|
@ndarilek I'm either going to file a new one today or transfer this one there. Need to decide if there is also work we want to do in Wrangler to include dotfiles. |
Thanks! I'd like to subscribe, so if it's a new issue, please link it here.
|
.well-known
Following up on the original issue, which is allowing The problem with supporting it by default in our preexisting code is that the Ignore crate adopts the This leaves us with other options to consider:
I could gravitate towards either of these options at this point. I don't really love either of them, though, because they simply just allow for the upload of hidden files. I'd prefer more granularity, where only |
From an end user perspective, I don't particularly mind which option
you go with. It's been a couple weeks since I worked with this so my
memory of the specifics isn't great, but I remember it being very
difficult to notice that these files were being ignored to begin with.
It only occurred to me after doing the upload to try hitting them via
curl, and when that failed, that wrangler may not be uploading dotfiles.
If you'd just make it clearer that certain files aren't being uploaded,
I think that'd help immensely. Or, given that dotfiles are used to
contain sensitive information, make it an error to initiate an upload
without explicitly including or excluding them. Again, I don't mind
which, I just wish it didn't fail quietly, or so quietly that I have to
use `--verbose` or equivalent to spot it.
Thanks.
|
Thank you for the feedback, @ndarilek! This is super helpful. I can definitely add a warning message about hidden files being ignored (and not have this lumped in under verbose output). |
I'd second automatically uploading On the second issue, files w/o an extension, how should I update this so that I serve only these files w/o extensions? I use Gatsby and I'm not exactly sure if I need the file name appending logic. Perhaps there's something a bit more precise than just removing the default behavior of Wrangler setups. |
I'd like to second, or third/fourth/whatever, including .well-known by
default as a fix for this issue. I've got a few sites I want to migrate,
and this is a big blocker since two include .well-known/matrix/server.
Right now these sit right at the sweet spot where they're mostly static
but need some dynamic behavior. I don't want to make them full-blown
SPAs, but at some point I'm going to want to do a bit of
header/cookie-based auth. Workers seems like a great fit, but I can't
lose Matrix server discovery support.
Thanks.
|
Here's a hacky potential workaround for some .well-known routes. In workers-site/index.js:
Would love to continue serving that as a static file, but for now it seems to work. Naturally, tweak for your own .well-known routes/path matches. |
For future people, I ended up with this: if (url.pathname == applePayPath) return new Response(applePayBody); It’s not really great and adding a lot more of these could get onerous and error-prone. I hope the team allows some built-in mechanism for this someday. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
So this isn't getting fixed? This whole trend of projects marking issues
as stale automatically has always baffled me. Someone else is just going
to have this issue in a few more months unless we routinely poke it to
keep it open.
FWIW, the lack of this feature put me off of using Cloudflare Workers to
host a static site. Not trying to seem harsh, but if Cloudflare's tools
are just going to arbitrarily not upload files from a directory, that's
kind of not what I want from anything advertising itself as a static
site hosting tool, and it might be good to rework the branding. I'll
still use Workers to intercept requests where needed, but if I can't
host .well-known files then there are several needs I just can't meet.
|
@ndarilek i'm going to update this issue to always upload Thank you for re-upping. |
.well-known
.well-known
dotfiles
I think @gabbifish 's comment still stands. The overrides truly do override all the existing paths in the crate we are depending on to walk the directory. This behavior seems really weird, so I've asked a question on the repository page. |
It looks like getting a fix for |
That would be a sad outcome 😔. We could make use of uploading invisibles to remove a bunch of really dumb hacks. |
Why not an explicit opt-in/opt-out field rather than toggling a boolean for all hidden directories? I'd like one sensical default behavior for what gets uploaded with the ability to opt in or out by directory pattern or file (e.g. |
Just wanted to chime in that my company is also trying to use Cloudflare Worker Sites because it was marketed as a static site hosting service, but issues like this make it hard for me to continue advocating for it... Our bundle doesn't currently have anything sensitive so I'll do combination of the above hacks for now - but this is pretty rough. |
Next step: we'll evaluate just doing this ourselves natively without a dependency on the Walkdir/Glob crates, since our use case is rather narrow. |
Wrangler doesn't appear to publish hidden files. In particular, I'm attempting to publish a Hugo site with public/.well-known/* (I.e. .well-known/keybase.txt, .well-known/matrix/server, etc.) These files are definitely in public/, but don't appear in the key list for the created namespace.
The text was updated successfully, but these errors were encountered: