CORSで土をすくう

Corsについてある程度知っていますが、
しばらくCors Errorに会ったことがありませんが、
突然また、Cors errorに出会って、苦労しました.
結論から言えば、原因は簡単すぎる.

これは,Cors OPTIONSリクエストに対する応答ヘッダの代わりに,以前のテスト時にインストールされたクロムアプリケーションが生成されたためである.
Corsの実行過程から,HTTPメソッドを要求する前にOPTIONS 方法は、preflightリクエスト(preflight、プリ転送)、すなわち、サーバがパラメータを含むリクエストを送信できるかどうかに応答するためにプリリクエストを送信することを可能にする.
このとき,Access-Control-Request-Methodヘッダに要求するメソッド名を記入する.
サーバは、要求可能なメソッド名をAccess-Control-Allow-Methodsに送信し、要求するメソッドがAccess-Control-Allow-Methodsに含まれていない場合、Corsエラーが発生します.

@Configuration
public class CorsConfig {

    @Bean
    public UrlBasedCorsConfigurationSource corsConfigurationSource() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true);
        config.addAllowedOrigin("http://localhost:3000"); 
        config.addAllowedHeader("*");  
        config.addAllowedMethod("*");
        config.addExposedHeader(JwtUtil.HEADER_STRING);
        config.addExposedHeader(JwtUtil.REFRESH_HEADER_STRING);

        source.registerCorsConfiguration("/**", config);
        return (source);
    }

}

Springサーバはすべてのメソッドを承認したが、エラーが発生したことは明らかです.
だから私は自分で答えに対応して死体検査をしました.



エラーは、PATCH要求が発行されたときに発生します.
上のレスポンスヘッドを見ると、PATCHがないことがわかります.
これは低クロムアプリケーションが自動的に生成する応答Headerであり、低クロムアプリケーションではPATCHを追加しないことによるエラーである.
Chromeアプリをオフにする

要求の方法については、Access-Control-Allow-Methodsヘッダが生成されていることがわかる.
注意:
OPTIONS - HTTP | MDN