[wpe-2.22] [wpe-2.28] Fetch POST not reusing persistent connection

[laurence-ejraee]

On any version of wpewebkit, carrying out multiple POST fetch request does not reuse the TCP connection and instead creates a new connection for each request.

For example with: fetch('https://reqres.in/api/articles', { method: "POST", body: JSON.stringify({ title: 'Fetch POST Request Example' }) });

On Chrome two calls to the above code reuse the connection from the first call. On wpewebkit it is not reused.

It is my understanding that persistent connections should be used here because the request and response headers have connection: keep-alive. Persistent connections should keep the TCP connection so that other fetches to the url can reuse the connection.

Question: Should multiple POST fetch requests reuse their connection like in Chrome or create a new connection for each request as seen?

[magomez]

@laurence-ejraee thanks for the report and for opening the upstream issue. I'll keep an eye on it and ensure to upgrade libsoup when it's fixed there.

[laurence-ejraee]

Following the response from libsoup on https://gitlab.gnome.org/GNOME/libsoup/-/issues/356 As they state a soup message flag can be provided from WebKit side to tell libsoup to allow connection reuse in the POST case.

I have created a patch for this: 0044-libsoup-reuse-connection-for-POSTs.patch.txt

Provided the patch in case you want to review or add a similar setting to allow developers the option of using connection reuse with libsoup.

[magomez]

Ok, I'll implement something like that to 2.22, 2.28 and 2.38 in case it's useful for someone else.

[magomez]

I've just pushed the patches to the three branches. There's just a small difference, which is that the env var name is WPE_POST_CONNECTION_REUSE, which is more appropriate than using the WEBKIT prefix. @laurence-ejraee , please, verify that the changes are working for you and close this issue.

[laurence-ejraee]

Sorry for the delay. Tested with wpe-2.28 and wpe-2.22 and its working. Thank you, closing.