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) -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/6a44f3ff-bc39-415b-ac53-e92ebe0edbb2%40googlegroups.com.
