Force Tampermonkey HTTP version when using fetch-CodePudding

I have a simple test TamperMonkey (Firefox) script that calls fetch.

The script is simple.

    (function() {
       'use strict';
       GM_registerMenuCommand("Test", postData);
    })();

    function postData(){
        fetch('https://https://httpbin.org/post', {
            method: 'POST',
            headers: HEADERS,
            body: JSON.stringify("{test:data}")
        })
    }

But running this exact same script on different websites gives different requests.

For instance here, on StackOverflow, and on most sites, it will make one HTTP/2 post. And it works.

(Anecdotally on some sites it will first send an OPTIONS request. It is not an issue but just emphasizing the fact that behavior can be different.)

On others (Twitter for instance), it will instead send an HTTP/1.1 POST. And then the API responds with a 202 and nothing happens (the post data that should be mirrored is not returned)

Is there a way to control which HTTP version TamperMonkey uses when making requests?

===

Following @DraganS's comment, I added the (Connection, upgrade) and (Upgrade, HTTP/2.0) headers. They do not seem to be taken into account (I don't see 'Upgrade' in the final request, and Connection is set to keep-alive. Interestingly though this makes the websites that didn't before send the OPTIONS request first. Not on Twitter though, that is still in HTTP/1.1

===

Edit 2: I was initially testing a specific API, but updating to a full testing script that sends requests to httpbin (that should just mirror the request) has the exact same behavior.

===

Starting to think it's not TamperMonkey related.

I'm not getting the error in Firefox but in Chrome, from the console, just doing a

fetch('https://httpbin.org/post', {
        method: 'POST',
        body: JSON.stringify('{}')
    })

on Twitter returns

Refused to connect to 'https://httpbin.org/post' because it violates the following Content Security Policy directive: "connect-src 'self' blob: https://*.giphy.com https://*.pscp.tv https://*.video.pscp.tv https://*.twimg.com https://api.twitter.com https://api-stream.twitter.com https://ads-api.twitter.com https://aa.twitter.com https://caps.twitter.com https://media.riffsy.com https://pay.twitter.com https://sentry.io https://ton.twitter.com https://twitter.com https://upload.twitter.com https://www.google-analytics.com https://accounts.google.com/gsi/status https://accounts.google.com/gsi/log https://app.link https://api2.branch.io https://bnc.lt wss://*.pscp.tv https://vmap.snappytv.com https://vmapstage.snappytv.com https://vmaprel.snappytv.com https://vmap.grabyo.com https://dhdsnappytv-vh.akamaihd.net https://pdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://mdhdsnappytv-vh.akamaihd.net https://mpdhdsnappytv-vh.akamaihd.net https://mmdhdsnappytv-vh.akamaihd.net https://dwo3ckksxlb0v.cloudfront.net".

So the cause would be a Twitter CORS policy ? Is it something that is avoidable ? Or does this mean it's just impossible to have a script making requests outside of these from twitter.com ?

CodePudding user response：

The fact that the HTTP version seen in Firefox is different is probably just a side effect.

The presence or not of a preflight OPTIONS request is normal behavior.

The error is due to to the CSP, not CORS like I initially thought (a lot of my previous errors were CORS related).

Solution: Do not use fetch, but the GM.xmlhttpRequest function. It is able to go around CSP, but you will not see it in the console.