Solución:
Comentario de Roy Fielding sobre la inclusión de un cuerpo con una solicitud GET.
Si. En otras palabras, cualquier mensaje de solicitud HTTP puede contener un cuerpo de mensaje y, por lo tanto, debe analizar los mensajes con eso en mente. La semántica del servidor para GET, sin embargo, está restringida de manera que un cuerpo, si lo hay, no tiene significado semántico para la solicitud. Los requisitos sobre análisis sintáctico son independientes de los requisitos sobre semántica de métodos.
Entonces, sí, puede enviar un cuerpo con GET, y no, nunca es útil hacerlo.
Esto es parte del diseño en capas de HTTP / 1.1 que se aclarará nuevamente una vez que se particione la especificación (trabajo en progreso).
…. Roy
Sí, puede enviar un cuerpo de solicitud con GET, pero no debería tener ningún significado. Si le da significado analizándolo en el servidor y cambiar su respuesta en función de su contenido, entonces está ignorando esta recomendación en la especificación HTTP / 1.1, sección 4.3:
… si el método de solicitud no incluye la semántica definida para un cuerpo de entidad, entonces el cuerpo del mensaje DEBE ignorarse al manejar la solicitud.
Y la descripción del método GET en la especificación HTTP / 1.1, sección 9.3:
El método GET significa recuperar cualquier información ([…]) se identifica mediante el Request-URI.
que establece que el cuerpo de la solicitud no es parte de la identificación del recurso en una solicitud GET, solo el URI de la solicitud.
Actualizar
El RFC2616 al que se hace referencia como “especificación HTTP / 1.1” ahora está obsoleto. En 2014 fue reemplazado por RFC 7230-7237. Se ha eliminado la cita “el cuerpo del mensaje DEBE ignorarse al manejar la solicitud”. Ahora es solo “El encuadre del mensaje de solicitud es independiente de la semántica del método, incluso si el método no define ningún uso para el cuerpo de un mensaje” La segunda cita “El método GET significa recuperar cualquier información … identificada por el URI de solicitud” fué borrado. – De un comentario
De la especificación HTTP 1.1 2014:
Una carga útil dentro de un mensaje de solicitud GET no tiene semántica definida; El envío de un cuerpo de carga útil en una solicitud GET puede hacer que algunas implementaciones existentes rechacen la solicitud.
Mientras tu pueden Haga eso, en la medida en que la especificación HTTP no lo excluya explícitamente, sugeriría evitarlo simplemente porque la gente no espera que las cosas funcionen de esa manera. Hay muchas fases en una cadena de solicitudes HTTP y, aunque “en su mayoría” se ajustan a la especificación HTTP, lo único que está seguro es que se comportarán como los utilizan tradicionalmente los navegadores web. (Estoy pensando en cosas como proxies transparentes, aceleradores, kits de herramientas A / V, etc.)
Este es el espíritu detrás del Principio de Robustez, aproximadamente “sea liberal en lo que acepta y conservador en lo que envía”, no quiere traspasar los límites de una especificación sin una buena razón.
Sin embargo, si tiene una buena razón, hágalo.
Es probable que encuentre problemas si alguna vez intenta aprovechar el almacenamiento en caché. Los proxies no se buscarán en el GET body para ver si los parámetros tienen un impacto en la respuesta.