Pregunta y escenarios adecuados
Eres responsable de un API gateway que puede filtrar adjuntos maliciosos, eliminar campos privados o transcodificar una respuesta. La solicitud al origen tiene éxito, pero la representación downstream ya no coincide con los bytes del origen. Explica cuándo retornar 203, cómo gestionar los validadores y cómo evitar que los clientes traten los datos transformados como datos autoritativos del origen.
HTTP 203 es una respuesta exitosa que indica que un proxy transformador modificó los encabezados o el contenido provenientes de la respuesta 200 del origen. Es una señal del protocolo para indicar “exitoso, pero transformado”, no un error genérico ni un estado de autorización.
Qué evalúa el entrevistador
- Límites precisos entre 203, 200, 304, 4xx y 5xx.
- Comprensión de cómo la transformación afecta a las cachés, ETags, firmas y solicitudes posteriores.
- Un vínculo de auditoría rastreable entre las representaciones del origen y las de downstream.
- Manejo de múltiples proxies, fallos del origen y clientes que no comprenden 203.
- Traducción de la semántica del protocolo en encabezados comprobables y comportamiento de caché.
Aclaraciones antes de responder
- ¿El cambio corresponde a filtrado de malware, transcodificación o redacción específica por usuario? Esto afecta la compartición en caché.
- ¿Pueden los clientes reconocer 203? Si no, ¿se requiere una capa de compatibilidad?
- ¿Debe ser rastreable la representación original? Las firmas y los registros de auditoría requieren ambas versiones.
- ¿La transformación es determinista? Si las reglas varían, la versión de la regla pertenece a la clave de caché.
Estructura de respuesta en 30 segundos
Primero verifico si el gateway modificó el contenido de la aplicación o encabezados relevantes. Una respuesta de origen exitosa con una representación alterada recibe 203; una representación intacta permanece en 200. 203 no reemplaza a 304, que solo valida la representación existente de un cliente. Genero un ETag para la representación downstream e incluyo la negociación de contenido, la versión de la regla y los límites de inquilino en la clave de caché. Los registros de auditoría vinculan la versión de origen con la salida transformada. Los fallos de origen mantienen su semántica de fallo real.
Respuesta detallada paso a paso
1. Establecer los límites de los códigos de estado
200 indica que la respuesta actual tuvo éxito sin declarar una transformación a nivel de aplicación. 203 indica que la solicitud tuvo éxito pero un proxy transformador modificó encabezados o contenido respecto al 200 del origen. 304 no transporta una nueva representación y solicita al cliente que reutilice una validada. El fallo de filtrado, el rechazo y el timeout del origen utilizan su semántica apropiada de 4xx o 5xx.
2. Clasificar la transformación
Reemplazar una URL bloqueada por malware, el filtrado de privacidad, la transcodificación de formato y los metadatos de réplica pueden justificar 203. Modificar únicamente la compresión de transferencia o campos hop-by-hop normalmente no cambia la representación de la aplicación. El gateway debe registrar qué cambió y por qué.
3. Recalcular validadores
Un ETag de origen describe la representación de origen. La salida transformada necesita un ETag downstream que sea válido para esa salida. Si una versión de regla cambia bytes, inclúyela en la clave de caché o en la entrada del validador; de lo contrario, un despliegue de reglas puede reutilizar salida obsoleta.
4. Diseñar el almacenamiento en caché y la negociación
Vary, la codificación de contenido, el idioma, el inquilino y la regla de transformación afectan la capacidad de compartir en caché. Establece por defecto los resultados sensibles a la privacidad en caché privada; comparte únicamente transformaciones públicas deterministas. Para If-None-Match, valida la representación del gateway en lugar de reenviar un 304 de origen para bytes que el cliente no posee.
5. Proteger firmas y pistas de auditoría
Una firma de origen sobre bytes originales no puede validar un cuerpo downstream modificado. Vuelve a firmar la representación transformada o elimina la firma inválida. Registra el ID de solicitud de origen, el ETag de origen, la versión de la regla, el ETag de salida y el motivo de la transformación.
6. Manejar múltiples proxies
Cada capa debe preservar la procedencia de la transformación y evitar repetir una regla no idempotente. Si un cliente no comprende 203, una capa de compatibilidad explícita puede retornar 200 con metadatos documentados, pero no debe ocultar silenciosamente una transformación de seguridad o privacidad.
7. Verificar y revertir
Prueba el 200 de origen, 203 transformado, 200 intacto, 304 downstream, despliegue de reglas, timeout de origen y fallo de filtrado. Durante la reversión, asegúrate de que los ETags antiguos y nuevos no puedan colisionar e inspecciona las entradas de caché compartida creadas bajo la regla anterior.
Respuesta de muestra de alta calidad
Trato 203 como la declaración “la solicitud tuvo éxito, pero un proxy transformador modificó la representación de origen”. Una respuesta de aplicación intacta permanece como 200; una transformada es 203; 304 solo valida la representación downstream y no se puede transferir a ciegas desde el origen. El gateway crea un nuevo ETag para los bytes transformados y define la clave de caché por versión de regla, negociación y límite de privacidad. Si la firma de origen cubría los bytes originales, el gateway vuelve a firmar o la elimina. Las pruebas cubren 200/203/304, cambios de reglas, cadenas de proxies y fallos de origen para que los clientes nunca confundan datos filtrados con datos de origen.
Errores comunes
- Retornar 203 para cada respuesta del proxy → la semántica se vuelve ruidosa → úsalo solo para un cambio real de representación.
- Reutilizar el ETag de origen → los validadores describen los bytes equivocados → genera uno para la salida downstream.
- Tratar 203 como un error → los clientes pueden reintentar o generar alertas → preserva la semántica de fallo 4xx/5xx real.
- Reenviar un 304 de origen a ciegas → la caché transformada puede no ser válida → valida la representación downstream.
- Ignorar las versiones de reglas → los despliegues pueden servir salidas obsoletas → incluye la versión en claves o validadores.
Preguntas de seguimiento y respuestas
¿Modificar únicamente Content-Encoding requiere 203?
Por lo general no. La codificación de transferencia es manejo a nivel de transporte; si la representación de la aplicación no cambia, mantén 200 y aplica las reglas normales de negociación.
¿Puede una respuesta 203 compartirse en una caché?
Sí, si la transformación es determinista, cada dimensión variable está indexada y no contiene datos privados del usuario. La salida específica por inquilino debe ser privada.
¿Qué sucede si un 203 de origen es transformado nuevamente por el gateway?
Preserva ambos enlaces de procedencia, calcula un ETag final y verifica la idempotencia. Si no se garantiza la idempotencia, permite solo una transformación.
¿Puede una capa de compatibilidad convertir 203 en 200?
Puede hacerlo cuando esté explícitamente documentado, con metadatos detectables y registro de auditoría. No debe ocultar silenciosamente el filtrado de seguridad ni la redacción de privacidad.
¿Qué sucede si el origen retorna 304 pero no existe un objeto transformado localmente?
No retornes 304 directamente. Obtén una representación utilizable y transfórmala, o retorna un fallo que refleje la falta de la representación local.