Updating pre-existing file in public folder without caching fails and produces 412
Opened this issue · 9 comments
I resolved this via storageClient.caching.enable('/public/MODULE_NAME/') and if I just write a second time it works, but I'm wondering why it is necessary to cache the potentially large public folder to write to it.
Maybe related to #887 or maybe I'm not handling conflict events properly like in #826
I'm wondering why it is necessary to cache the potentially large public folder to write to it
That's not the case per se (and definitely not intended). Sharesome uses zero caching and only the public folder for example. But it doesn't overwrite existing files. So it could very well be a bug with 412 handling in public directories.
If it works on the second try, then it sounds very much like there's a conflict on the first try. You would see the 412 status in the network tab of your browser console then.
@rosano Which caching strategy did the code use when you encountered this behavior?
@skddc I always use caching.enable which defaults to ALL, but this was not on the public folder.
If it works on the second try, then it sounds very much like there's a conflict on the first try. You would see the 412 status in the network tab of your browser console then.
Yes this happens every first try when caching is not enabled for the public folder. I guess for me it's strange to call it a 'conflict' because I always intend to write to it without caring what's there, and it seems like the 'most recent wins' doesn't apply in this case.
That would be a bug then. But it could also be a bug on the server side. Does it actually send an ETAG to check for conflicts in the PUT request headers?
Edit: It would be the If-Match header. If the server's version differs from what is sent, then it returns the 412.
Here are the headers I can see in Safari:
The If-None-Match: * header means "only create the file if it doesn't exist on the server yet". That's why the server is responding with a 412.
Looks like a bug to me. The library doesn't know of the already existing file and thinks it's creating a completely new one.
So when caching is disabled, I think it should not send that header. But that would put the responsibility of making sure to not overwrite any existing files unintentionally to the app, not the library.
But that would put the responsibility of making sure to not overwrite any existing files unintentionally to the app, not the library.
I wonder if it's merely an edge case to treat the public folder as "always writeable without concern about conflicts" or if it is worth making a flag for this somewhere in the library? If the app primarily writes to the private folder, then public is usually just a secondary copy that can be safely overwritten – from a UX perspective, I would imagine that the person using the app sees it that way as well.
I'm wondering if we need some kind of force-overwrite argument for the PUT functions, in order to ensure that implementors are aware of the situation.
I'm wondering if we need some kind of force-overwrite argument for the PUT functions, in order to ensure that implementors are aware of the situation.
Oh yes it would be even more clear if it happened on a per-call basis, not globally as I had imagined.