CORS Preflight - Vems fel? Min och/eller serverns?

Tjo! Jag har bråkat med "CORS Preflight" nu med min REST API-tjänst som enbart fungerar lokalt eller på min studentserver när både webbplatsen och REST API-webbtjänsten är på samma server. Vad som inte fungerar är att antingen anropa REST API:t när jag kör localhost eller från Netlify (därmed annat domän än där REST API:t ligger).

- Jag har provat med .htacess-fil på studentservern. Fungerade ej.

Jag har följande startkod i REST API-filen som innehåller en koll på XHR OPTIONS (behövs annars ej när allt är på samma server):

<?php
// Headers configuration for REST API Web Service
//header('Access-Control-Allow-Origin: *'); // All domains can send requests to it
header('Access-Control-Allow-Origin: https://maka2207-restapi-webb3.netlify.app'); // Only Netlify page now?

header('Content-Type: application/json; utf-8;'); // Type of content it sends back in its responses

header('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS'); // Allowed HTTP request methods it will respond to

// Allowed headers the client can use - fixing possible CORS issues here 
header('Access-Control-Allow-Headers: Access-Control-Allow-Headers, Content-Type, Access-Control-Allow-Methods, Authorization, X-Requested-With');

// Allow preflight requests for CORS, bcuz "unmentioned reasons" 
// (I'm actually a little bit pissed off that this was NOT shown 
// in Lectures about creating CORS-compatible REST API!).
// ARE YOU SURE, there is NO NEED for an .htaccess file in the MIUN STUDENT WEB SERVER?
// The .htaccess file inside of the /api/ folder where index.php is did not work...
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
    header('Access-Control-Allow-Headers: Access-Control-Allow-Headers, Content-Type, Access-Control-Allow-Methods, Authorization, X-Requested-With');
}

Koden ovan där if-satsen börjar löser dock inget, samma fel igen: XHR OPTIONS-begäran nekas och CORS Preflight misslyckas.

- Jag har dubbelkontrollerat att det är https:// som försöker anropa https:// så det inte blir konflikt där. Gör jag fel där så fungerar inte https://-anrop om jag skulle ladda in på webbplatsens http://-version för fetch-anropet görs till en förbestämd https://-länk så.

- Koden ovan visar också hur jag senast provat att endast tillåta Netlify-hemsidan (därmed annat domän än där REST API ligger). Men det fungerar inte heller.

- REST API-filerna ligger i en mapp som heter "writeable" som används för att kunna läsa och skriva till filer på studentservern vilket fungerar då jag har kunna lagt upp WordPress som sedan installerats på studentservern.

Jag försöker lista ut om det är jag som gjort något fel i början av min REST API PHP-kod? Koden är alltså de första raderna som ska tillåta CORS (dock provat mot Netlify senast, annars var det alla = *) och sedan löpa på.

Jag ska mejla lärarna nu och fråga, men jag blir så himla paff att jag skulle få icke-godkänt på en hel kurs på grund av en detalj som kanske inte ens är mitt fel? Alltså att studentservern inte är konfigurerad (eller just mitt studentkonto) för att tillåta CORS och därmed få CORS Preflight-hindret.

Jag har inte fått svar ännu från någon annan i min virtuella klass som kanske också kör Netlify och uppladdat på samma studentserver som jag och som det ändå fungerar för utan CORS Preflight-hinder. Hur kan jag veta om felet ligger i min REST API-kod och/eller om felet ligger i student-serverkontot?

OBS: Jag får endast CORS Preflight-hindret för HTTP-metoderna POST/PUT/DELETE, inte GET. GET fungerar som det ska.

Mvh,
WKL.

GLADA NYHETER: Jag har hittat problemet:

Det utkommenterade nu orsakade felet:

        // When a non-supported request method was used
        // default:
        //     resCode(405); // HRC: Method Not Allowed
        //     $res = resMsg("Webbtjänsten stödjer ej denna HTTP-metod.");
        //     break;

default skickar alltså http_response_code 405 om andra metoder än PUT, GET, POST, DELETE används för jag har ingen case 'OPTIONS': för min switch().

Detta gjorde då att övriga anrop (förutom GET) nekades direkt efter att 405 skickats redan vid XHR OTPIONS-anropet.

Så sjukt att den lilla detaljen bråkat med mig så länge!

Det betyder alltså att så fort 405 skickats tillbaka så nekar REST API alla övriga seriella CRUD-anrop från klienten?

Mvh,
WKL.