Mike, the second version of the Key-Value server API uses encryption on the inner request payload which means the HTTP cache won't find exact matches for requests (as encryption results in non-determinism) independent of HTTP method. I will look at whether PUT or POST makes more sense.
On Wed, Mar 27, 2024 at 1:57 PM Mike Taylor <miketa...@chromium.org> wrote: > On 3/25/24 12:44 PM, 'Paul Jensen' via blink-dev wrote: > > On Wed, Mar 20, 2024 at 2:02 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > > If I understand correctly what y'all are trying to do here, you're trying > to effectively recreate with GETs what should've been a POST. > Is the reasoning for that outlined somewhere? > > POSTs have many advantages over GETs when transferring large amounts of > data to the server. Most importantly, they tend to actually pass through. > Beyond that, the data is not typically saved to logs (whereas URLs often > are). Finally, in theory POST request bodies could be compressed, although > that's rarely used in practice. > > You make good points about POST vs GET usage here, and we agree with most > of them. We in fact announced our plans to transition the Protected > Audience trusted signals fetches to POST and add compression > <https://github.com/WICG/turtledove/commit/d58a984d9088978b9ee9012a8ab869addfea2d1a> > more than a year ago in our version 2 of the API. GET, however, has the > huge advantage of facilitating HTTP caching in the browser while it’s > proving very complicated to architect and implement caching for the trusted > signals fetches when POST is used. We’re making good progress towards this > new caching and protocol version 2, but it’s going to take more time, so > splitting up trusted signals fetches is necessary until version 2 is ready. > > > https://github.com/WICG/turtledove/blob/main/FLEDGE_Key_Value_Server_API.md#binaryhttp-the-packaging-layer-for-http-kv-service-requests > states that the method is PUT, not POST. Is that a typo? My understanding > is that a response to a PUT request is not cacheable. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrmUs7psCPzXRVER4Fuyh781YLnu6yqqH4mAbvD5Ut%3DDig%40mail.gmail.com.
