¿Cómo resuelvo un error HTTP 414 "Solicitar URI demasiado largo"?

103

He desarrollado una aplicación web PHP. Le estoy dando una opción al usuario para actualizar varios problemas de una sola vez. Al hacerlo, a veces el usuario se encuentra con este error. ¿Hay alguna forma de aumentar la longitud de la URL en apache?

php apache http-status-codes JPro
fuente
Si ve este error en un servidor de Windows y / o en una aplicación IIS / ASP.NET, consulte la pregunta: stackoverflow.com/q/23237538/12484
Jon Schneider

Respuestas:

166

Bajo Apache, el límite es un valor configurable, LimitRequestLine. Cambie este valor a algo más grande que el predeterminado de 8190 si desea admitir un URI de solicitud más largo. El valor está en /etc/apache2/apache2.conf . De lo contrario, agregue una nueva línea ( LimitRequestLine 10000) debajo AccessFileName .htaccess.

Sin embargo, tenga en cuenta que si realmente está llegando a este límite, probablemente esté abusando GETpara empezar. Debe usar POSTpara transmitir este tipo de datos, especialmente porque incluso admite que los está usando para actualizar valores. Si revisa el enlace anterior, notará que Apache incluso dice "En condiciones normales, el valor predeterminado no debe cambiarse".

John Feminella
fuente
Intenté usar POST al principio, pero esta es una operación de actualización en la base de datos y estoy actualizando la página original usando los valores que se publicaron originalmente en esa página.
JPro
8
JPro: Actualizar una base de datos es más o menos la razón exacta que usaría POST. Nada sobre el uso de POST le impide completar el mismo formulario con los campos que se acaban de publicar, por lo que no estoy seguro de lo que quiere decir con eso.
John Feminella
1
@JPro: La técnica habitual en ese caso es PUBLICAR en la misma página. El controlador de la página (que puede ser el mismo código tanto para GET como para POST) primero verifica los parámetros POST, los maneja si los encuentra, luego devuelve la página con los valores correctos completados, que serán los valores actualizados ( si POST y la actualización tienen éxito) o los valores originales (si GET, o si POST y la actualización fallan). Si la actualización falla, incluso puede tener mensajes de error por campo que describan la falla.
Mike DeSimone
5
Me di cuenta de esto bastante tarde, así que me gustaría compartirlo. Si no puede encontrar la palabra LimitRequestLineen ningún lugar de su archivo httpd.conf, simplemente agregue la línea en cualquier lugar que desee. Por ejemplo:LimitRequestLine 100000
Jules Colle
gracias por la respuesta y la explicación, me salvaste el día. :)
may saghira
16

Según la respuesta de John, cambié la solicitud GET a una solicitud POST. Funciona, sin tener que cambiar la configuración del servidor. Así que busqué cómo implementar esto. Las siguientes páginas fueron útiles:

Ejemplo de POST de jQuery Ajax con PHP ( tenga en cuenta el comentario de desinfectar datos publicados) y

http://www.openjs.com/articles/ajax_xmlhttp_using_post.php

Básicamente, la diferencia es que la solicitud GET tiene la URL y los parámetros en una cadena y luego envía nulo:

http.open("GET", url+"?"+params, true);
http.send(null);

mientras que la solicitud POST envía la URL y los parámetros en comandos separados:

http.open("POST", url, true);
http.send(params);

Aquí hay un ejemplo de trabajo:

ajaxPOST.html:

<html>
<head>
<script type="text/javascript">
    function ajaxPOSTTest() {
        try {
            // Opera 8.0+, Firefox, Safari
            ajaxPOSTTestRequest = new XMLHttpRequest();
        } catch (e) {
            // Internet Explorer Browsers
            try {
                ajaxPOSTTestRequest = new ActiveXObject("Msxml2.XMLHTTP");
            } catch (e) {
                try {
                    ajaxPOSTTestRequest = new ActiveXObject("Microsoft.XMLHTTP");
                } catch (e) {
                    // Something went wrong
                    alert("Your browser broke!");
                    return false;
                }
            }
        }

        ajaxPOSTTestRequest.onreadystatechange = ajaxCalled_POSTTest;
        var url = "ajaxPOST.php";
        var params = "lorem=ipsum&name=binny";
        ajaxPOSTTestRequest.open("POST", url, true);
        ajaxPOSTTestRequest.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
        ajaxPOSTTestRequest.send(params);
    }

    //Create a function that will receive data sent from the server
    function ajaxCalled_POSTTest() {
        if (ajaxPOSTTestRequest.readyState == 4) {
            document.getElementById("output").innerHTML = ajaxPOSTTestRequest.responseText;
        }
    }
</script>

</head>
<body>
    <button onclick="ajaxPOSTTest()">ajax POST Test</button>
    <div id="output"></div>
</body>
</html>

ajaxPOST.php:

<?php

$lorem=$_POST['lorem'];
print $lorem.'<br>';

?>

Envié más de 12.000 caracteres sin ningún problema.

atmelino
fuente
4

Tengo una solución sencilla.

Suponga que su URI tiene una cadena stringdatademasiado larga. Simplemente puede dividirlo en varias partes según los límites de su servidor. Luego envíe el primero, en mi caso para escribir un archivo. Luego envíe los siguientes para agregarlos a los datos agregados anteriormente.

Shrey Gupta
fuente
¿Puede dar un ejemplo? Puedo ver cómo divide la cadena cuando es generada por el usuario ...
endyourif
4
Solución alternativa muy barata. ¡Es mejor reconsiderar el problema del dominio!
Muhammad Hewedy
13
Esto no merece tener tantos votos negativos. Ciertamente, hay situaciones en las que enviar varias solicitudes puede ser una solución alternativa aceptable. Es cierto que la calidad de la respuesta es un poco baja, pero eso es de esperar de un usuario que es nuevo en SO. ¡Demostremos algo de amor y ofrezcamos comentarios en lugar de simplemente rechazar a los recién llegados que todavía no "entienden" SO!
rinogo
1
Estoy de acuerdo, parece viable
Felipe Valdés
3

Recibí este error después de usar $ .getJSON () de JQuery. Acabo de cambiar para publicar:

data = getDataObjectByForm(form);
var jqxhr = $.post(url, data, function(){}, 'json')
    .done(function (response) {
        if (response instanceof Object)
            var json = response;
        else
            var json = $.parseJSON(response);
        // console.log(response);
        // console.log(json);
        jsonToDom(json);
        if (json.reload != undefined && json.reload)
            location.reload();
        $("body").delay(1000).css("cursor", "default");
    })
    .fail(function (jqxhr, textStatus, error) {
        var err = textStatus + ", " + error;
        console.log("Request Failed: " + err);
        alert("Fehler!");
    });
Software Fusca
fuente
2
¿Es esta una respuesta o una pregunta?
Takarii
Esta es una buena solución rápida. Cambiar de llegar a publicar permite la URL larga sin ningún cambio en la configuración del servidor.
mt025
1

Un extracto del RFC 2616: Protocolo de transferencia de hipertexto - HTTP / 1.1 :

El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el Request-URI en la Request-Line. POST está diseñado para permitir un método uniforme para cubrir las siguientes funciones:

  • Anotación de recursos existentes;
  • Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo similar de artículos;
  • Proporcionar un bloque de datos, como el resultado de enviar un formulario, a un proceso de manejo de datos ;
  • Ampliación de una base de datos mediante una operación de adición.
Tu sentido común
fuente
8
¿No ves cómo esto responde a la pregunta ...?
Afr
El cartel original decía que los registros se están actualizando. Para las actualizaciones, es una buena práctica utilizar POST o PUT y no GET. Pero, por supuesto, es posible que se exceda el límite máximo de URL al recuperar los registros para mostrar antes de actualizar, y luego el método GET es apropiado, pero puede fallar debido a este límite. El póster original no mencionó en qué etapa surge el problema, por lo que se puede suponer que fue durante la actualización en sí, pero no podemos estar seguros ...
JustAMartin