VueJS在Android Chromium中localhost API请求异常求助

Hey there, let's dig into why your Axios POST request is acting up on older Chromium versions—especially since other apps can hit the API just fine. Here are the most likely culprits and fixes to try:

1. Fix Axios Configuration Mistakes #

First, I spotted a couple of easy-to-miss errors in your Axios setup that could be throwing off old browsers:

• You used contentType: "application/json" as a top-level config, but Axios expects this to live in the headers object with the correct camelCase name: Content-Type.
• Manually building the Basic Auth header might lead to encoding glitches in older Chromium. Instead, use Axios's built-in auth parameter to handle this automatically (it’s more reliable for legacy environments).

Here’s the corrected config:

var axiosConfig = {
  method: "post",
  url: "http://localhost:8225/info/update",
  data: {},
  timeout: 3000,
  headers: {
    "Content-Type": "application/json" // Fixed header placement and naming
  },
  auth: { // Let Axios handle Basic Auth encoding safely
    username: apiUser,
    password: apiPassword
  }
};

return new Promise(function (resolve, reject) {
  axios(axiosConfig)
    .then(function (response) {
      console.log("Response", response);
      resolve(response);
    })
    .catch(function (error) {
      console.log("Error", error);
      reject(error);
    });
});

2. Check CORS Preflight (OPTIONS) Handling #

Since your request includes an Authorization header, Chromium will send an OPTIONS preflight request before the actual POST. If your backend’s HttpListener doesn’t properly respond to this OPTIONS request, the browser will stall the POST (leading to pending/timeout errors).

Make sure your backend returns these headers for OPTIONS requests:

• Access-Control-Allow-Origin: * (restrict it to your Vue app’s origin if possible for better security)
• Access-Control-Allow-Methods: POST, OPTIONS
• Access-Control-Allow-Headers: Authorization, Content-Type
• Return a 200 OK status code for OPTIONS requests.

Other apps might skip CORS preflight checks entirely, which is why they work even if the backend isn’t handling OPTIONS correctly.

3. Verify Basic Auth Encoding (If You Stick to Manual Setup) #

If you still want to build the Authorization header manually, double-check that the encoding works for old Chromium:

• Legacy btoa functions struggle with non-ASCII characters in usernames/passwords. Encode them first with encodeURIComponent:

  const encodedUser = encodeURIComponent(apiUser);
  const encodedPass = encodeURIComponent(apiPassword);
  const authHeader = "Basic " + btoa(encodedUser + ":" + encodedPass);
  

• Use Chromium’s Network tab to confirm the Authorization header is correctly formatted (starts with Basic followed by a valid base64 string).

4. Rule Out Chromium-Specific Restrictions #

Older Chromium versions (pre-v80) on Android 4.4.4 have stricter security policies:

• Ensure your local API uses HTTP (not HTTPS) — Android 4.4.4’s TLS stack doesn’t support modern cipher suites, which would break HTTPS connections.
• Quick check: Head to chrome://settings/security to make sure no settings are blocking local network requests (unlikely, but worth eliminating).

Final Debugging Steps #

1. Use Chromium’s Network tab to inspect the request:
   • Check if the OPTIONS request is being sent and what response it receives.
   • Verify the Authorization and Content-Type headers are present and correct.
2. Test the corrected Axios config first — that’s the most likely fix here.

内容的提问来源于stack exchange，提问作者Somya Sharma