empty directories not cleaned up

[michielbdejong]

i found out that heahdk doesn't clean up directories once they're empty, there is now an empty directory myfavoritedrinks/a/ on my storage ([email protected])

[michielbdejong]

btw i think what i did to get this was:

PUT /myfavoritedrinks/a/b/c
DELETE /myfavoritedrinks/a/b/c

it looks like /myfavoritedrinks/a/b/ was deleted but /myfavoritedrinks/a/ was not

[michielbdejong]

ah no wait, this is probably a bug in remoteStorage.js, not in the server

[michielbdejong]

right, what happens is, the library thinks these directories still exist. they don't, but heahdk is returning a 304 instead of a 404. this is in response to an 'If-None-Match' header with an ETag, which is very odd, because afaik neither should the library be sending those, nor should the server be returning them, because the storageType is "https://www.w3.org/community/rww/wiki/read-write-web-00#simple", which off the top of my head didn't even have Last-Modified headers yet. Even if it were remotestorage-00, it shouldn't be using ETags, they're part of the remotestorage-01 spec which isn't even out yet.

[michielbdejong]

it may be that Rails is inserting the ETag headers and Firefox is reacting to them?

[nilclass]

remoteStorage.js doesn't implement If-Non-Match / ETag headers yet, so I would guess as well that it's the browser's caching. Rails automatically generates ETags, which usually isn't a problem when they are correct. I guess we can deactivate them for now.

[nilclass]

Actually I don't see any ETags now in the response. Maybe I already deactivated them. But there is a "Last-Modified" header and when setting "If-Modified-Since" in the request to a later time, it generates a "304 Not Modified" response.

[nilclass]

I'm stripping the Last-Modified header from the response now. Not the cleanest way to do it, but it works for me: ae5900b (already deployed on heahdk.net)

[johnknapp]

I'm totally new to this project but notice the draft spec for remotestorage requires ETags on server responses, so proper ETag implementation probably ought to remain an open issue, yes? LMK if I interpret this correctly and maybe I can work on that.

[michielbdejong]

@johnknapp hi! you're right, but this server still offers the preceding version of remoteStorage, 2012-04. so yes, if and when this server is updated to remotestorage-00 or remotestorage-01 (which we're currently drafting in gh:remotestorage/spec), the ETags should be added back :)

[nilclass]

true. -> #8

@michielbdejong, did the changes here solve your problem?

[michielbdejong]

@nilclass no, i'm still receiving ETag headers and i'm still sending If-None-Match headers. this is while using myfavoritedrinks connected to heahdk with firefox

[michielbdejong]

ah wait, just saw the other ticket :)

it looks like it's fixed now yes, i will reopen if i can reproduce it again.