Caching POST responses in IndexedDB (bug?) + reading from indexeddb cannot be disabled

[Benjamin Golinvaux]

Hello

First post here. Hello everyone :)

I noticed two weird things and I'd like to check I am not dreaming.

First, a minor issue : I tried to use the following flags when performing an http request : EMSCRIPTEN_FETCH_LOAD_TO_MEMORY | EMSCRIPTEN_FETCH_PERSIST_FILE.
Then, later, I reverted to using only EMSCRIPTEN_FETCH_LOAD_TO_MEMORY.
I noticed that the emscripten fetch code always looks up the entry in the IndexedDB first, even with only the EMSCRIPTEN_FETCH_LOAD_TO_MEMORY flag specified. In that particular case, the existing entries in IndexedDB from my previous attempt were interfering with my requests (since I am quite new to web development -- I am now in it thanks to emscripten :) -- I did not know about the whole IndexedDB stuff and wasted some time trying to understand that). Don't you think that, by default, IndexedDB should not be used at all ?

The real problem I have encountered : I was performing a REST API call on some server (Orthanc) with a POST request. The responses were returned from the existing IndexedDB entries and, furthermore, it seems that only part of the body is used in the index : hundreds of calls to this endpoint, with different bodies, were always returning the responses of the first request.

My first question : shouldn't it be better to use the same rules to store the response in IndexedDB that the browser uses ? (POST not cached by default unless some header is added) ?

My second question (the important one) : is this possible that two POST requests with same URI but different bodies (only different after 30 characters or something) return the same stored response ?

Thanks a lot in advance for your help sorting this out.

Best,

Benjamin Golinvaux

(Belgium)