Recientemente estuve investigando cadenas de consulta HTTP mientras me preguntaba acerca de las posibilidades en la interfaz de acceso al servicio webAPI. Y parece muy subespecificado.

De hechoRFC 3986 (Identificador uniforme de recursos (URI): sintaxis genérica) no dice nada sobre el formato del fragmento de cadena de consulta y termina definiendo qué caracteres están permitidos y cómo codificar otros caracteres. (Volveré a esto más adelante.)

Lo único que encontré fue una especificación HTML sobre cómo se modifican los formularios en la cadena de consulta (HTML 4.01; 17.13.4 Tipos de contenido de formulario, application / x-www-form-urlencoded). El algoritmo HTML 5 parece lo suficientemente cerca (4.10.22.5 Datos de formulario codificados en URL).

Esto puede parecer bien. Después de todo, ¿por qué alguien querría establecer un formato de cadena de consulta para todos los demás? ¿Para qué? Pero, ¿hay algún otro (que no sea HTML) estándares bien establecidos? ¿Alguien más está usando un formato diferente?

Una pregunta lateral aquí es tratar con [] en los nombres de campos de formulario. PHP lo utiliza para garantizar que todas las apariciones de un campo estén presentes en$_GET Variable superglobal. (De lo contrario, sólo está presente la última aparición).

Pero de dondeRFC 3986 parece que ninguno[ ni] se permiten en la cadena de consulta. Sin embargo, mis experimentos con varios navegadores sugirieron que ningún navegador codifica esos caracteres y están ahí en el URI de esa manera ...

¿Es esta la práctica de la vida real? ¿O lo estoy probando incorrectamente? Probé con PHP 5.3.17 en IIS 7. Usando Internet Explorer, Firefox y Chrome. Luego comparé lo que hay en$_SERVER['QUERY_STRING'] y$_GET.

Otra pregunta es el soporte de la vida real para la separación de punto y coma.

Especificación HTML 4.01 (B.2.2 Ampersands en los valores de atributo URI) recomienda servidores HTTP para aceptar punto y coma (;) como separador de parámetros (opuesto a un símbolo&).

¿Algún servidor lo soporta? ¿Alguien está usando esto? ¿Vale la pena preocuparse por eso (cuando se consideran los formatos permitidos de cadena de consulta para un servicio web)?

Entonces, ¿qué hay de compatibilidad con caracteres no ASCII?

Especificación HTML 4.01 (B.2.1 Caracteres no ASCII en valores de atributo URI) reitera claramente qué URI que describe las RFC se estableció en primer lugar: los caracteres que no son ASCII no están permitidos en URI. Sin embargo, la especificación tiene en cuenta la práctica existente (de uso de URI ilegales) y consejos para cambiar dichos caracteres en codificación UTF-8 y luego tratar cada byte con codificación hexadecimal estándar URI.

De mis pruebas parece que por ejemplo Chrome y Firefox lo hacen. Pero Internet Explorer no lo hizo y solo envió a esos personajes como si fueran. PHP hizo frente parcialmente a eso.$_SERVER['QUERY_STRING'] y$_GET contenía esos personajes. Pero$_SERVER['REQUEST_URI'] contenida? en lugar.

¿Existen normas o prácticas de cómo abordar estos casos?

Y otra pregunta relacionada es ¿cómo deberían los autores publicar (por URI) recursos con nombres que no contengan caracteres ASCII (por ejemplo, nacionales)? Teniendo en cuenta las distintas partes (código HTML, solicitud de envío del navegador, archivo de guardado del disco guardado en disco, solicitud de procesamiento y recepción del servidor y almacenamiento del archivo en el servidor), parece casi imposible que funcione de manera consistente. O al menos nunca lo logré.

Cuando se trata de páginas web, ya estoy acostumbrado a eso y siempre sustituyo los caracteres nacionales por los caracteres base latinos correspondientes. Pero cuando se trata de archivos externos (archivos PDF, imágenes, ...) de alguna manera, "se siente mal" para "degradar" los nombres. Especialmente si uno espera que los usuarios guarden esos archivos en el disco ... ¿Cómo lidiar con este problema?