¿Consideraría la especificación CORS que un encabezado Content-Type faltante implicaría un "encabezado simple"?

RFC 7231, Sección 3.1.1.5 indica:

  

Un remitente que genera un mensaje que contiene un cuerpo de carga útil DEBERÍA   generar un campo de encabezado Content-Type en ese mensaje a menos que el   El tipo de medio deseado de la representación adjunta es desconocido para el   remitente. Si un campo de encabezado Content-Type no está presente, el destinatario   PUEDE asumir un tipo de medio de application/octet-stream   ( [RFC2046], Sección 4.5.1 ) o examine los datos para determinar su tipo.

La recomendación CORS afirma:

  

Se dice que un encabezado es un encabezado simple si el nombre del campo del encabezado es un   Coincidencia de mayúsculas y minúsculas en ASCII para Accept , Accept-Language , o    Content-Language o si es una coincidencia ASCII insensible a mayúsculas y minúsculas para    Content-Type y el tipo de medio del valor del campo del encabezado (excluyendo   parámetros) es una coincidencia ASCII insensible a mayúsculas y minúsculas para    application/x-www-form-urlencoded , multipart/form-data o text/plain .

Esto parece crear un caso no especificado para las implementaciones CORS en POST, porque el uso de application/octet-stream fuerza el caso encabezado no simple , y "examinar los datos para determinar su tipo" no es trivial.

¿Qué es lo más razonable que se puede hacer en los siguientes casos?

• La longitud del contenido de la solicitud es 0. (Me gustaría asumir Content-Type: text/plain para habilitar el caso encabezado simple .)
• Content-Length no es cero. (El valor predeterminado es application/octet-stream y forzar el caso de cabecera no simple )

Para abordar un comentario relacionado con si CORS es una medida de seguridad o solo un modelo para compartir recursos, estoy agregando información adicional sobre las implicaciones de estos casos de borde. Sí, CORS es ciertamente un modelo para compartir recursos. Sin embargo, el uso compartido de recursos funcionó bien sin CORS, hasta que los clientes HTTP agregaron medidas de seguridad para evitar explícitamente la recuperación de recursos de origen cruzado. Si se implementa incorrectamente, el componente del lado del servidor de CORS puede reabrir algunos de esos agujeros de seguridad al compartir recursos de manera inadecuada, especialmente cuando se trata de credenciales. Estos casos de borde son caminos que (según la respuesta a las preguntas anteriores) conducen directamente a la sección sobre si se deben permitir solicitudes de recursos con credenciales de origen cruzado.

La determinación de lo que constituye un encabezado simple frente a un encabezado no simple en los casos de borde anteriores afecta si algunas solicitudes se consideran solicitudes simples o no, que a su vez pone en vigencia la Parte 4: Consideraciones de seguridad:

  

Se ha definido una solicitud de origen cruzado simple como congruente con aquellas   que pueden ser generados por los agentes de usuario desplegados actualmente que no lo hacen   cumplir con esta especificación. Solicitudes simples de origen cruzado generadas   fuera de esta especificación (como las presentaciones de formularios de origen cruzado   utilizando GET o POST o solicitudes GET de origen cruzado resultantes del script   elementos) normalmente incluyen credenciales de usuario, por lo que los recursos conformes   a esta especificación siempre debe estar preparado para esperar simple   solicitudes de origen cruzado con credenciales.

     

Debido a esto, los recursos para los cuales las solicitudes simples tienen importancia   Los que no sean de recuperación deben protegerse de la solicitud entre sitios.   Falsificación (CSRF) al requerir la inclusión de un token no descargable en   El contenido explícitamente proporcionado de la solicitud.