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/4bdc9eee-c6f0-488c-9f19-ea44e19379b8%40chromium.org.
